- Issue created by @poker10
- 🇸🇰Slovakia poker10
I propose these changes:
Add something like we have on s.d.o, which clearly mention not to commit anything and to read the policy. I think this is beneficial and the link is also very important. So I suggest to add:
Maintainers, please do not commit any code until directed to do so. Please review http://drupal.org/node/101497 for more information.
---------------------
The message is great. I found that we have some additional information in the current message on s.d.o., which is probably worth considering:
As soon as you make the releases, update this issue with the URLs to the releases.
- I asked in 📌 Decide which labels are needed for Active , if we can automate this somehow and add a comment to the gitlab issue, when a private release is created. If yes, then I think we do not need this part of the message added back. If not, then I would probably add it, as it seems valuable to track progress (at least for me).Commit the code and create the release nodes between 16:00 UTC Tuesday and 16:00 UTC Wednesday
- We have part of this in the new message (16:00 UTC Wednesday). Can we update the new message to include also the starting time (so to inform they, that they can start commiting from 16.00 UTC on Tuesdays)? If this message will be added on 8:30 UTC on Tuesdays, there is still a gap until the commit window for maintainers opens. So maybe we can update this part of the new message and add it somehow (but sorry, can't think of any good wording now):Maintainers - before the release window opens, commit the fixes to the public, ...
- 🇺🇸United States drumm NY, US
automate this somehow and add a comment to the gitlab issue, when a private release is created
That’s doable, but there isn’t anything linking the release to a specific security issue. So we’d have to comment on every open security issue for the project. That’s probably not a problem, although might be annoying if there are many open security issues for the project. In any case, implementation would have to be in packaging, so the many API requests to find and comment on the issues wouldn’t delay a web request.
We might want to go ahead and post a comment for every release, including non-security, so that we can spot active maintainers who might have missed the security issue, and other unexpected workflows.
- 🇺🇸United States drumm NY, US
On release creation, we could offer to link the release to drafted advisories, updating that advisory’s “Fixed in” field. That’s probably the way to go. If the advisory exists, that does have a link to the specific security issue.
- 🇺🇸United States drumm NY, US
Can we update the new message to include also the starting time (so to inform they, that they can start commiting from 16.00 UTC on Tuesdays)? If this message will be added on 8:30 UTC on Tuesdays, there is still a gap until the commit window for maintainers opens.
Adjusting what time of day the daily messages are posted is an option too. The current time is somewhat arbitrary. My thinking so far has been that its better to be a bit early, and its better to have a maintainer make the release a few hours early than them running late.
- 🇺🇸United States drumm NY, US
Add something like we have on s.d.o, which clearly mention not to commit anything and to read the policy. I think this is beneficial and the link is also very important. So I suggest to add:
Added in https://git.drupalcode.org/project/drupalorg/-/commit/00580c709adb36c0c7..., I made the language a little more direct.
On release creation, we could offer to link the release to drafted advisories, updating that advisory’s “Fixed in” field. That’s probably the way to go. If the advisory exists, that does have a link to the specific security issue.
Done in https://git.drupalcode.org/project/drupalorg/-/commit/0b2ff674daf7908716... & https://git.drupalcode.org/project/drupalorg/-/commit/47f37bb9d44f61f67f.... This also posts to the advisory’s issue when a Fixed in release is added to the advisory.
Remaining work here is now potentially adjusting the “Release window open” message and/or timing. Details are in comment #2 & #5.