Release Managers should _own_ Security Releases

Porting over from https://gitlab.slack.com/archives/releases/p1489694361015309

  • ernst: Wondering if an edit to the release-managers page makes sense to clarify ordering / priority / responsibility of doing a security release. Over in https://gitlab.com/gitlab-org/release-tools/blob/master/doc/release-manager.md it says "Post-release: The amount and scheduling of patch releases is entirely at the discretion of the release manager (with the exception of security releases, which should be addressed immediately).” which would indicate that as soon as @briann adds the Next Patch Release label to his security release issue, it should become the RM’s first and top priority. Is that reasonable though?
  • stanhu: It really depends on the vulnerability and the urgency of the security release. If it's a critical problem (e.g. admin impersonation bug), we should make it the top priority. Otherwise, there will be times when the RMs prefer to focus on getting the release out on time for the 22nd rather than being distracted by a security release that can wait a few days after the 22nd.
  • ernst: Thanks, that makes sense. But we need an owner of a security release, and I feel it should be the Release Managers, not @briann . Does that make sense?
  • stanhu: Yes. I nominate the previous release manager because the current (e.g. 9.0) one may be too busy trying to deal with all the 9.0 release issues
  • ernst: 🤔 Interesting! Will they not end up bumping into each other a bunch? The current RM for the current release and the prior RM for the security release?
  • stanhu: Yeah, it's tricky because a security release often touches 3 releases in total... it's a lot for one person usually

Proposal: assign the RM from release N-1 (where the current release is N) to own Security Releases that need to occur during the same time as the RM for release N is working on release N.

Pros:

  • Clear ownership
  • Having worked on N-1 may help in releasing the security releases which typically happen for N-1 through N-3.
  • Potentially assist current RM if needed to unblock the Security Release.

Cons:

  • Possibly get in each other's way, delaying both the Security Release and the regular release.