Open Stack

On 26/03/2018 14:33, Thierry Carrez wrote:
> 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.

It is more complex than just "joining that team" if the project follows
stable policy. the stable team have to approve the additions, and do
reject people trying to join them. I don't want to have a release where
someone has to self approve / ninja approve patches due to cores *not*
having the access rights that they previously had.

> 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 !
>