📣 Security release changes for development
🗺 Overview
The Delivery group is working on improving the Security Release process to enable multiple security releases each month.
The changes to the process will push actionable communication to engineers working on security fixes. This means less confusion, less waiting for responses, and less risk of missing a security release.
Please add any questions and feedback to this issue.
Timeline
These changes are in effect for the 16.5 security release, which will occur after 2023-10-22.
👣 Process change
(See security release terminology for definitions of specific issue type names used here).
The only specific change from the Developer perspective exists in the security issue workflow template. A new security-target label automatically links your issue to the upcoming release.
Make sure to follow the guidance on the issue template to meet all requirements:
Assigning to a release
IMPORTANT: When this issue is ready for release (Default branch MR and backports are approved and ready to be merged), apply the security-target label.
- The
gitlab-release-tools-bot
evaluates and links issues with the label to the next planned security release tracking issue. If the bot finds the issue is not ready to be included in the security release, it will leave a comment on the issue explaining what needs to be done.- This issue will only be included in a security release if it is successfully linked to the security release tracking issue.
From there, all of the communication described will be automatic. You will receive pings for any actions to take or problems to resolve.
Open security implementation issues with the security-notifications label will have comments posted on them, pinging the assignee, when the stable branch is created, prompting to create the final backport. This label is automatically added to all new security implementation issues.
This new process is fully documented in the Release Docs with specific details for Developers.