Include bug fixes in the security release blog post.
Delivery is working to extend the GitLab maintenance policy to support bug fixes to the two previous monthly releases in addition to the current stable release (&828 (closed)). This brings the patch release policy to par with the security release one. Part of the work to extend the maintenance policy will open up the stable branches to allow engineers to merge bug fixes directly into the stable branch.
Merging bug fixes into stable branches can be done at any time during the release cycle, this impacts the security release content: when a security release is tagged and published, the security release package can contain bug fixes, besides the expected security fixes. GitLab stakeholders (internal and external) should be aware the security release package contains non-security and security patches.
The purpose of this issue is to agree on a process to notify GitLab stakeholders about the inclusion of bug fixes in a security release.
Proposal: Include bug fixes in the security release blog post.
After a security release is completed, a blog post is published on GitLab social media to encourage all GitLab installations to be upgraded to the latest versions. To re-use the current communication process, the security release blog post structure can be amplified to include a section for non-security patches, for reference, this has been done before with good results (example).
To expand the security release blog post structure:
- DRI Delivery - The security release task template will need to be expanded as well to:
- Include a step for fetching the dedicated list of bug fixes to be included in the security release.
- Communicate to the AppSec team about the list of bug fixes to be included.
- The steps should be done before merging the security backports. #2934 (closed)
- DRI AppSec - Include a section on the security release blog post for non-security patches https://gitlab.com/gitlab-com/gl-security/appsec/tooling/security-release-tools/-/issues/36