Re: [openstack-dev] [stable][release] Remove complex ACL changes around releases
On Wed, Mar 28, 2018 at 03:34:32PM +0100, Graham Hayes wrote: > 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. This is true but when we (I) say no I explain what's required to get $project-stable-maint for the requested people. Which typically boils down to "do the reviews that show they grok the stable policy" and we set a short runway (typically 3 months) It is absolutely that same as joining *any* core team. > 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. You can always ping stable-maint-core to avoid that. Looking at recent stable reviews stable-maint-core and releease-managers have been doing a pretty good job there. And as this will happen in July/August there's plenty of time for it to be a non-issue. Yours Tony. [1] https://review.openstack.org/#/admin/groups/101,members [2] https://review.openstack.org/#/admin/groups/1098,members signature.asc Description: PGP signature __ 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
Re: [openstack-dev] [stable][release] Remove complex ACL changes around releases
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 ! > __ 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
Re: [openstack-dev] [stable][release] Remove complex ACL changes around releases
On Wed, Mar 28, 2018 at 09:51:34AM -0400, Doug Hellmann wrote: > Excerpts from Thierry Carrez's message of 2018-03-26 15:33:03 +0200: > > 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. > > +1 to not doing things we no longer consider useful > +1 to keeping things simple. __ 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
Re: [openstack-dev] [stable][release] Remove complex ACL changes around releases
Excerpts from Thierry Carrez's message of 2018-03-26 15:33:03 +0200: > 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. +1 to not doing things we no longer consider useful __ 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
Re: [openstack-dev] [stable][release] Remove complex ACL changes around releases
LGTM __ 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
Re: [openstack-dev] [stable][release] Remove complex ACL changes around releases
On Mon, Mar 26, 2018 at 03:33:03PM +0200, Thierry Carrez wrote: > Let me know if you have any comment, otherwise we'll start using that > new process for the Rocky cycle (stable/rocky branch). Sounds good to me, Thanks Thierry Yours Tony. signature.asc Description: PGP signature __ 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
[openstack-dev] [stable][release] Remove complex ACL changes around releases
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
