Backport release procedure change?
We had a security release last week and the pains of old release procedure were quite visible.
Security releases are very difficult in themselves without the release procedure complications. What was especially difficult was the package promotion (and I think even stressful), as it was ultimately confusing for all involved. According to @jamedjo, release for 9.4 RC4 was uneventful (at least when it comes to the release itself).
Sadly, security releases are not going to go away so I am looking into ways on how to simplify this in future.
I suggest we backport all changes done in #2071 (closed) to previous 3 release stable branches.
Why we should consider not doing this:
- Backporting 10ish MR's to older branches is going to be time consuming
- I expect a lot of conflicts
- If something is skipped, we will only see it during the release
Why we should consider doing this:
- Release managers would have to full control of completing the release
- No separate package promotion is needed
- Same procedure for the current release as for the older ones.
Given how much (collective) time we spend on security releases, I think the benefit outweighs the effort. We would also need to think how far back we would want to backport.
It would be great to hear the opinions about this @rymai @jamedjo @mikegreiling @briann @stanhu and @gitlab-build-team .
Activity
IMHO, with regards to how far back, we should port these changes back as far as our supported versions list as is current. E.g. any version that we'd put out a security release for, as opposed to recommending a version update to a more current version branch. I default to @briann on the number of back versions for this.
@marin I think that makes sense to avoid additional stress when releasing a security release.
The policy is to backport to the previous two releases. I chose to request further backports in this case for three reasons:
- It contained critical patches.
- The last critical release did not get backported far enough and we received a bunch of requests for diffs.
- This particular release fell on a boundary. I know we still have a lot of users on 8.17 and I wanted to make sure they received the critical fixes. That meant 5 versions which has historically been the right choice for critical releases.
The security team doesn't have to deal with the pain of the backports so I'm happy to go with whatever you decide for changing the release process.
I think this would be a worthwhile endeavor. When we released the latest security patch, we needed @twk3 on standby to perform the package promotion step. Putting the package promotion into the hands of the RMs would make coordination efforts much smoother.
assigned to @marin
changed milestone to %9.5
mentioned in merge request !1792 (merged)
mentioned in merge request !1793 (closed)
Backport list:
https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1602 https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1636 https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1641 https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1633 https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1659 https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1661 https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1610 https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1683 https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1728 https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1736 https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1750mentioned in merge request !1794 (merged)
mentioned in merge request !1795 (closed)
mentioned in merge request !1796 (merged)
mentioned in merge request !1797 (merged)
mentioned in merge request !1801 (merged)
mentioned in merge request !1802 (merged)
mentioned in merge request release-tools!172 (merged)
@briann @mikegreiling @jamedjo @jivanvl @psimyn
9.2 and 9.3 have been updated to use the same build procedure as 9.4
