New patch release process: Internal pilot logistics
Context
As part of extending the maintenance policy, an internal pilot will be driven during 15.10, empowering engineers into merging changes to the current stable branch. This should give us early feedback on the new process while allowing the release managers to perform patch releases to the current version.
This is an issue to keep track of the internal pilot requirements and progress
Analyze if #2840 (closed) is required. => Not a requirement for an internal pilot. Still a good issue to complete for the maintenance policy extension.
Update protected branch rules for 15-10-stable-ee branch: maintainers should be able to merge and the gitlab-release-tools-bot should be able to push#2890 (comment 1323085037)
3 MRs from GitLab Runner are using the Pick into 15.10. These projects use the label to indicate to their release managers (that are independent of the GitLab release managers) that the merge requests should be cherry-picked into the stable branches. Nothing to do in this case.
The MR merged into the stable branch skipped the QA review. The review was required because the package-and-test pipeline failed. In this case, no further action is required because the failure is unrelated. but this could be a good sign that #2840 (closed). I've noted this on gitlab-org/gitlab!115465 (comment 1326328456)
The CNG MR didn't use the required template. This is not a big deal, but I've opened a MR to mention that on the runbook gitlab-org/release/docs!570 (diffs)
The name of the package-and-test pipeline differs a bit from the one stated in the stable branch template. The stable branch template has e2e:package-and-test and the actual name is e2e:package-and-test-ee, this is not a big deal but it might be a good idea to update the template to avoid confusion. gitlab-org/gitlab!116611 (merged)
There is a JiHu contribution gitlab-org/gitlab!115820 (merged), they're struggling a bit because there is no SET dedicated to them, so the process, in this case, is to ask for assistance on the Quality channel. This could be an indicator to reinforce this process to the Quality department. => This was handled internally.
The danger message is clunky, for example gitlab-org/gitlab!116604 (comment 1339704313). The following sections do not apply to backports: intelligence checks, database review, this MR is quite large, and perhaps even the new migrations message. Reducing the Danger messages could highlight the package-and-qa warning which is an important one. => #2950 (closed)
When a maintainer opened up an MR targeting a stable branch they would be able to merge without approvals, this is because code owner approval is not required on stable branches. Requiring this approval would enforce multiple approvals for backports, so instead a "merge request rule was added", this rule enforces a single approval on backports from maintainers (backend, frontend, database, quality or docs team). Details on #2886 (comment 1348667596)
The patch release pressure indicates there are high-priority backports waiting to be released but it is not straightforward to know which are those MRs. => #2954
The patch release pressure combines the S1/S2 severities together, this is handy but it might be informative to have the S1 pressure differentiated from the S2, because having 2 S1's is different from having 2 S2's. => #2955
The blog post is automatically generated when the release manager starts the patch release process, in between the process starts and the patch release is tagged, a new backport can be merged into the stable branch. There is no easy way to notice this, automation might be needed in this case. => #2954
During this pilot, the patch release template requires removing all steps associated with previous versions, it might save some manual work to update the template to always use the latest version. => gitlab-org/release-tools!2288 (merged)
Closer to the 15.11
Analyze the patch release performance under the new workflow. #2947 (closed)
Reinforce the internal pilot also applies for 15.11