Open Stack

 ---- On Fri, 01 Jul 2022 10:31:16 -0500  Stephen Finucane <stephenfin at redhat.com> wrote --- 
 > tl;dr: Who should be able project-specific stable-maint groups on Gerrit:
 > members of the projects-specific stable-maint group itself or members of stable-
 > maint-core?
 > 
 > A recent discussion on #openstack-sdks highlighted some discrepancies in the
 > ownership of various project-specific "stable-maint" groups on Gerrit. As a
 > reminder, any project that specifies "stable:follows-policy" is required to
 > follow the stable branch policy (suprise!). This is documented rather well at
 > [1]. We expect people who have the ability to merge patches to stable branches
 > to understand and apply this policy. Initially the only people that could do
 > this were peopled added to a central Gerrit group called "stable-maint-core"
 > group, however, in recent years this responsibility has been devolved to the
 > projects themselves. Each project with a stable branch now has a project-
 > specific stable maintenance Gerrit group called PROJECTNAME-stable-maint (e.g.
 > nova-stable-maint [2].
 > 
 > The issue here is who should *own* these groups. The owner of a Gerrit group is
 > the only one that's able to modify it. In general, the owner of a Gerrit group
 > is the group itself so for example the owner of python-openstackclient-core is
 > python-openstackclient-core [3]. This means that if you're a member of the group
 > then you can add or remove members, rename the group, set a description etc.
 > However, _most_ PROJECTNAmE-stable-maint groups are owned by the old 'stable-
 > maint-core' group, meaning only members of this global group can modify the
 > project-specific groups. I say _most_ because this isn't applied across the
 > board. The following projects are owned by 'stable-maint-core':
 > 
 >  * barbican-stable-maint
 >  * ceilometer-stable-maint
 >  * cinder-stable-maint
 >  * designate-stable-maint
 >  * glance-stable-maint
 >  * heat-stable-maint
 >  * horizon-stable-maint
 >  * ironic-stable-maint
 >  * keystone-stable-maint
 >  * manila-stable-maint
 >  * neutron-stable-maint
 >  * nova-stable-maint
 >  * oslo-stable-maint
 >  * python-openstackclient-stable-maint
 >  * sahara-stable-maint
 >  * swift-stable-maint
 >  * trove-stable-maint
 >  * zaqar-stable-maint
 > 
 > However, the following stable groups "own themselves":
 > 
 >  * ansible-collections-openstack-stable-maint
 >  * aodh-stable-maint
 >  * congress-stable-maint
 >  * freezer-stable-maint
 >  * karbor-stable-maint
 >  * mistral-stable-maint
 >  * neutron-dynamic-routing-stable-maint
 >  * neutron-lib-stable-maint
 >  * neutron-vpnaas-stable-maint
 >  * octavia-stable-maint
 >  * openstacksdk-stable-maint
 >  * oslo-vmware-stable-maint
 >  * ovn-octavia-provider-stable-maint
 >  * panko-stable-maint
 >  * placement-stable-maint
 >  * sahara-dashboard-stable-maint
 >  * senlin-dashboard-stable-maint
 >  * senlin-stable-maint
 >  * telemetry-stable-maint
 > 
 > This brings me to my question (finally!): do we want to resolve this
 > discrepancy, and if so, how? Personally, I would lean towards delegating this
 > entirely to the projects but I don't know if this requires TC involvement to do.
 > If we want to insist on the stable-maint group owning all PROJECT-stable-maint
 > branches then we have a lot of cleanup to do!

You understanding is right that it is delegated to project etirely.

In Xena cycle, TC passed the resolution about decentralize the stable branch core team
to projects
- https://governance.openstack.org/tc/resolutions/20210923-stable-core-team.html

and We updated the project-team-guide also to have project manage the project specific
stable core group
- https://review.opendev.org/c/openstack/project-team-guide/+/834794

It is own by the project and they can manage this group  the same way they manage the master
branch core group.

-gmann

 > 
 > Cheers,
 > Stephen
 > 
 > PS: This might be a good moment to do a cleanup of members of various stable
 > branches that have since moved on...
 > 
 > [1] https://docs.openstack.org/project-team-guide/stable-branches.html
 > [2] https://review.opendev.org/admin/groups/21ce6c287ea33809980b2dec53915b07830cdb11
 > [3] https://review.opendev.org/admin/groups/aa0f197fcfbd4fcebeff921567ed3b48cd330a4c
 > 
 > 
 >