Proposal: Align the stable branch permissions with the current GitLab maintenance policy.
Context
While testing the new patch release process during the internal pilot, protected branch and merge request rules were created to allow maintainers to merge into the 15.10 and 15.11 stable branches. With the decision of the maintenance policy extension being on hold (details on #2947 (closed)), there has been confusion across Engineering departments regarding if bug fixes can be merged into stable branches older than the current version (example).
Having stable branches outside of the Maintenance policy has some considerable disadvantages:
- Backporting bug fixes in older branches is against the maintenance policy for bug fixes.
- There is some confusion on the Engineering department and Release manager's side regarding if bug fixes can be merged into stable branches older than the current version
- Establishes a discrepancy in the process: Engineers can merge into out-of-bound branches with the hopes that maybe one day there will be a release for a higher-priority bug.
On the other side, having stable branches opened to maintainers (regardless the version) has the following benefits on the release managers' side:
- Removes a direct dependency from Release Managers - If fixes for stable branches are needed, release manager intervention is required. This implicitly delegates the responsibility of healthy stable branches to the Delivery team (when it is a shared responsibility across Engineering)
To allow for the new patch release process to be fully adopted while continuing to respect the maintenance policy, the stable branch permissions should reflect the current state of the GitLab maintenance policy.
Proposal: Align the stable branch permissions with the current GitLab maintenance policy.
To remove uncertainty about the maintenance policy extension, the stable branch permissions should reflect the current state of the policy for bug fixes, that is, maintainers should only be allowed to merge to the current stable branch.
For each release, release managers will adjust the protected branch and the merge request rules respectively to account for the current version, branches outside the maintenance policy will be limited to release managers.
Pros
- Meets maintenance policy guidelines - Patch releases will continue to be prepared for the current version only.
- Prevents confusion from the engineering side regarding when to expect patch releases.
- Respects the current backport request process.
- Prevents merges from older versions (< 15.10) not adept for a self-serve approach.
Cons:
- Creates manual work to release managers - At the end of each release, release managers will have to adjust the protected branch and merge request rules to the current version.
- Creates a dependency to release managers - Release managers will be pinged every time a merge request is merged into stable branches out of policy, e.g. backporting flaky failures, doc changes, and bug fixes to older versions will require explicit approval from release managers.
To do
-
GitLab project: Adjust the protected branch and the merge request rules #7226 (comment 1390875730) -
Managed Versioning: Adjust the protected branch and the merge request rules #7226 (comment 1391134294) -
Add a step on the monthly release for release managers to manually adjust these rules. gitlab-org/release-tools!2372 (merged) / gitlab-org/release-tools!2374 (merged) -
Update the current release issue gitlab-org/release/tasks#5345 (closed) -
Document the stable branch configuration gitlab-org/release/docs!591 (merged) -
Considering the benefits of having stable branches opened for release managers, involve product to take a decision regarding the permissions of stable branches. #7226 (comment 1392777900)