Hi! TL;DR: We used to do complex things with ACLs for stable/* branches around releases. Let's stop doing that as it's not really useful anyway, and just trust the $project-stable-maint teams to do the right thing.
Current situation: As we get close to the end of a release cycle, we start creating stable/$series branches to refine what is likely to become a part of the coordinated release at the end of the cycle. After release, that same stable/$series branch is used to backport fixes and issue further point releases. The rules to apply for approving changes to stable/$series differ slightly depending on whether you are pre-release or post-release. To reflect that, we use two different groups. Pre-release the branch is controlled by the $project-release group (and Release Managers) and post-release the branch is controlled by the $project-stable-maint group (and stable-maint-core). To switch between the two without blocking on an infra ACL change, the release team enters a complex dance where we initially create an ACL for stable/$series, giving control of it to a $project-release-branch group, whose membership is reset at every cycle to contain $project-release. At release time, we update $project-release-branch Gerrit group membership to contain $project-stable-maint instead. Then we get rid of the stable/$series ACL altogether. This process is a bit complex and error-prone (and we tend to have to re-learn it every cycle). It's also designed for a time when we expected completely-different people to be in -release and -stable-maint groups, while those are actually, most of the time, the same people. Furthermore, with more and more deliverables being released under the cycle-with-intermediary model, pre-release and post-release approval rules are actually more and more of the same. Proposal: By default, let's just have $project-stable-maint control stable/*. We no longer create new ACLs for stable/$series every cycle, we no longer switch from $project-release control to $project-stable-maint control. The release team no longer does anything around stable branch ACLs or groups during the release cycle. That way, the same group ends up being used to control stable/* pre-release and post-release. They were mostly the same people already: Release managers are a part of stable-maint-core, which is included in every $project-stable-maint anyway, so they retain control. What that changes for you: If you are part of $project-release but not part of $project-stable-maint, you'll probably want to join that team. If you review pre-release changes on a stable branch for a cycle-with-milestones deliverable, you will have to remember that the rules there are slightly different from stable branch approval rules. In doubt, do not approve, and ask. But I don't like that! I prefer tight ACLs! While we do not recommend it, every team can still specify more complex ACLs to control their stable branches. As long as the "Release Managers" group retains ability to approve changes pre-release (and stable-maint-core retains ability to approve changes post-release), more specific ACLs are fine. Let me know if you have any comment, otherwise we'll start using that new process for the Rocky cycle (stable/rocky branch). Thanks ! -- Thierry Carrez (ttx) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
