Open Stack

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)