Status of this module

[donquixote]

Hello @slootjes !

After a long time dealing only with Drupal 7, I finally rediscovered this module, and remember all the good times. (#3, #4).
I see a number of nice changes were done.

However, on the module page I see:

• Usage count = 1.
• Not covered by security policy.

The usage count does not mean it is abandoned - I have similar projects on D7 which suffer the same fate. But this makes it hard to propose this for a corporate environment, and risky to base another contrib module on it.

Do you have plans for this module? Or perhaps everybody downloads the module from github instead of drupal.org?

Background

What happened is I had modules lying around that I was planning to publish a D8 version of (cfr / renderkit / entdisp etc), and that was using my own hacked version of controller annotations. Not a good state for publishing.

I then noticed that you implemented some of the ideas, especially the RouteModifierInterface, which was then split into two distinct interfaces for class and method. And you are passing the reflection class + method to the route modifier. Cool stuff!
I also notice that the nasty dependency is gone.

As a first step I rebased all my custom modifications on the latest version of the module, and made it match the new API, to see what would be left. I will have to review the changes and decide which of them still make sense. Perhaps some pull requests will be born from that.

For #3 I now have a dedicated module with some additional route modifiers.

[slootjes]

Hi :) Good to hear from you again! To me the module is feature complete and I don't think many people are using it since it's not documented or referenced anywhere really. It will unfortunately never be covered by security policy as I intended this module to show off a more Symfony/PSR style of working.

[donquixote]

What would you sacrifice if you opt into security policy?

…

On Mon, 6 Jan 2020, 13:59 Robert Slootjes ***@***.***> wrote: Hi :) Good to hear from you again! To me the module is feature complete and I don't think many people are using it since it's not documented or referenced anywhere really. It will unfortunately never be covered by security policy as I intended this module to show off a more Symfony/PSR style of working. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#13?email_source=notifications&email_token=AABEUEEAGZ4XGZMUJ4JYE3DQ4MTK3A5CNFSM4KC5XHI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIFL2UA#issuecomment-571129168>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABEUEF37DCA35OI3HH5HH3Q4MTK3ANCNFSM4KC5XHIQ> .

[slootjes]

Nothing really tbh. I've created other modules which do follow all Drupal standards however controller annotations is more experimental and I'd like to leave it like that. If that is not good enough for getting a security status then I can live with that.

[donquixote]

but does the security policy require drupal code style?

…

On Mon, 6 Jan 2020, 14:05 Robert Slootjes ***@***.***> wrote: Nothing really tbh. I've created other modules which do follow all Drupal standards however controller annotations is more experimental and I'd like to leave it like that. If that is not good enough for getting a security status then I can live with that. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#13?email_source=notifications&email_token=AABEUEDOQHCO3WAVADUGLA3Q4MUBXA5CNFSM4KC5XHI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIFMIIQ#issuecomment-571130914>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABEUEFBMMZF4NE5ZL2IZ2TQ4MUBXANCNFSM4KC5XHIQ> .

[slootjes]

Yep; that was the only reason it got rejected.

[donquixote]

If you say experimental, does this mean you might want to BC break the API occasionally? Or does it only mean it is a bit unorthodox in its idea?

…

On Mon, 6 Jan 2020, 14:07 Andreas Hennings ***@***.***> wrote: but does the security policy require drupal code style? On Mon, 6 Jan 2020, 14:05 Robert Slootjes ***@***.***> wrote: > Nothing really tbh. I've created other modules which do follow all Drupal > standards however controller annotations is more experimental and I'd like > to leave it like that. If that is not good enough for getting a security > status then I can live with that. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#13?email_source=notifications&email_token=AABEUEDOQHCO3WAVADUGLA3Q4MUBXA5CNFSM4KC5XHI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIFMIIQ#issuecomment-571130914>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AABEUEFBMMZF4NE5ZL2IZ2TQ4MUBXANCNFSM4KC5XHIQ> > . >

[donquixote]

Those blockheads 🙂 On the other hand, I guess it makes sense to use Drupal CS for modules, and PSR for composer packages.

…

On Mon, 6 Jan 2020, 14:09 Robert Slootjes ***@***.***> wrote: Yep; that was the only reason it got rejected. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#13?email_source=notifications&email_token=AABEUECRO4UE4NVG34S5PULQ4MUQNA5CNFSM4KC5XHI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIFMQSY#issuecomment-571131979>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABEUEFPCGIMXCDR4LVXYLLQ4MUQNANCNFSM4KC5XHIQ> .

[slootjes]

It's just unorthodox and requires technical experience. It should be compatible with D8 and probably D9 too.

[donquixote]

It's a shame, like this I wont be able to convince my org / colleages to use it, and wont use it in my contrib modules. I think annotations are much more git-friendly than long yml files, because you avoid unrelated commits in the same file. Are you actively using the module in your own projects? And what if we would change the CS, would this feel wrong to you?

…

On Mon, 6 Jan 2020, 14:14 Robert Slootjes ***@***.***> wrote: It's just unorthodox and requires technical experience. It should be compatible with D8 and probably D9 too. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#13?email_source=notifications&email_token=AABEUEAIO6B6Y4S5XII6HX3Q4MVEHA5CNFSM4KC5XHI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIFM4WI#issuecomment-571133529>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABEUEDMYQPJHYINV6DYIMTQ4MVEHANCNFSM4KC5XHIQ> .

[slootjes]

Your org / colleages should worry less about contrib having no security label imo. The security label doesn't mean that much as there is no guarantee the code has no security issues and after the status is obtained it is never really checked again afterwards. The concept is great but I am not sure if it really solves anything.

[donquixote]

The security policy means there is a well-defined channel and process where

• people can report security issues they find, in a private issue queue
• the issue being discussed and a patch prepared in the private issue queue, only involving the maintainer, the sec team and the reporter.
• scheduled release
• notifications sent out via the security mailinglist
• information via the update module

It does not mean that the security team will actively and continuously monitor the module. The system depends on 3rd party people who report issues they find.

Your org / colleages should worry less about

It is a big one, public sector :) There are processes and gatekeepers, and a general preference for policies that can be "formalized".

[slootjes]

Fair enough. We handle these differently for our tools as stated on the project page (f you discover any security related issues, please email [email protected] instead of using the issue tracker.). For now I have no real intention to refactor everything using Drupal coding style.

Feel free to do with the code as you wish as it's compliant withGPL version 2: https://www.drupal.org/about/licensing

[donquixote]

I could fork it, but I would prefer not to if the only reason is code style.. Perhaps I will do a PR with phpcbf, then you can decide what to do with it. (it would be multiple commits each with specific steps, not all at once).

…

On Mon, 6 Jan 2020, 16:58 Robert Slootjes ***@***.***> wrote: Fair enough. We handle these differently for our tools as stated on the project page (f you discover any security related issues, please email ***@***.*** instead of using the issue tracker.). For now I have no real intention to refactor everything using Drupal coding style. Feel free to do with the code as you wish as it's compliant withGPL version 2: https://www.drupal.org/about/licensing — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#13?email_source=notifications&email_token=AABEUEFMCD6WD4R4TQARXJDQ4NILZA5CNFSM4KC5XHI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIF35YA#issuecomment-571195104>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABEUED3UZ3EVWAC3HZDZHLQ4NILZANCNFSM4KC5XHIQ> .

[donquixote]

Hi
I am running into this conundrum again :)

If I were to find the time to attempt to make this more compliant with Drupal standards, which way would you prefer or support?

• I propose a pull request to this module, OR
• I become a maintainer and start working on a new major version, OR
• I create a "fork" named e.g. "route_annotations"?

[slootjes]

Considering this module hasn't been updated in 2 years I'd recommend to fork it. Would appreciate it if you could mention this project as inspiration. Good luck, have fun :)

[donquixote]

Ok!
I am sure somebody will complain about duplication of modules, but what can we do..

[CountCount]

@donquixote Did you actually fork it? Coming from a Symfony 5 project to a Drupal 9 project, I'd love to use Route Annotations in Drupal as well. Any chance this will be supported by Drupal in the future?