Proposal: Align blog post to patch release terminology
Context
Blog posts for security and patch releases are automatically generated by release tooling. As part of &1193 (closed), the term "patch releases" is being repurposed for releases that include bug and security fixes, which is one of the last steps to officially combine patch and security releases into a single scheduled type, details on #20015 (closed). T
The practice of automatically generating the blog post during the patch release process will continue as-is. This issue is to identify the areas of the blog post that need to be updated to account for the new terminology.
State-of-art
The blog post consists of 6 sections
- Title indicating the type of release and the targeted versions
- A summary informing the content of the release
- A section for security fixes: Composed by a high-overview table and a description of each fix
- A section for bug fixes: A list of bug fixes sorted per version
- A generic section linking to the update information and to subscribe to security notifications
- Social media actions
Last 5 security release / patch release blog posts:
- https://about.gitlab.com/releases/2024/02/07/security-release-gitlab-16-8-2-released/
- https://about.gitlab.com/releases/2024/01/12/gitlab-16-7-3-released/
- https://about.gitlab.com/releases/2024/01/25/critical-security-release-gitlab-16-8-1-released/
- https://about.gitlab.com/releases/2024/01/11/critical-security-release-gitlab-16-7-2-released/
- https://about.gitlab.com/releases/2023/12/13/security-release-gitlab-16-6-2-released/
Proposal: Blog post adjustments to account for patch release terminology
For the blog post to be aligned with the patch release term, the following updates will be required:
- The title should be updated from
Security release
toPatch release
- The content of the summary section should be updated to use
Patch release
- The file name should be updated from
YYYY/MM/DD/security-release-gitlab-m-n-x-released/
toYYYY/MM/DD/patch-release-gitlab-m-n-x-released/
The remaining sections, including the ones for security and bug fixes, stay the same.
Considerations
- What happens if the patch release doesn't include bug fixes?
Considering bug fixes to the current version can be self-serve and the ongoing influx of backport requests, this would be an edge case. In any event, the blog post should not include the Patch release
section.
For starters, the "bug fix" section can be manually dropped from the blog post. On upcoming iterations, the blog post tooling generator can be updated to skip this section if the patch doesn't include any bug fix
- What happens if the patch release doesn't include security fixes?
Since 16.7, two security releases have been performed per month, each of these releases included a good number of security fixes (details: 1, 2). Based on the former, it'd also be an edge case for a patch release to not include any security fix.
In this event, the security section can be manually dropped. Later, the blog post tooling generator can be updated to skip this section if the patch doesn't include security fixes.
In this event, AppSec should not be involved so the blog post:
- Should be assigned to release managers, specifying the blog post doesn't contain any security fixes
- AppSec should be notified about this so no security alerts are sent.
- Where should the blog post be created?
The blog post will always be created on security, regardless if it includes security fixes or not. In another iteration, the generation can be smarter to create the blog post on canonical if the patch release only includes bug fixes and on security if the patch includes security fixes.
- What categories should be used in the blog post?
At the moment security blog posts are in the:
- Releases: https://about.gitlab.com/releases/categories/releases/
- Security: https://about.gitlab.com/blog/categories/security/
If the patch release includes bug and security fixes, the categories stay the same. If the patch release only includes bug fixes, the category should be Releases
only
To do
Implementation details
-
Update blog post title, content and file name gitlab-org/release-tools!2972 (merged) -
Skip the bug fixes section if no bug fixes are present gitlab-org/release-tools!2979 (merged) -
Skip the security fixes section if no security fixes are present gitlab-org/release-tools!2979 (merged) -
Add the patch release blog post to upcoming ones #20054 (closed) -
Assign release managers if the blog post doesn't include security fixes, assign appsec if the blog post include security fixes (already implemented) -
Adjust the blog post based on AppSec observations gitlab-org/release-tools!2992 (merged) -
Follow-up: Notify release managers when the blog post does... (#20150 - closed) -
Follow up: Patch releases: Detect if no security fixes are... (#20100) -
Follow up: Create the blog post in canonical if the patch release doesn't include security fixes. => This is already the case - code -
Follow up: Document how the patch release blog post works (#20152) -
Follow up: Drop the blog post link after 17.x (#20153)
Template
-
A blog post template should be created and agreed with AppSec gitlab-com/www-gitlab-com!133685 (closed)