[all][tc][gerrit] Ownership of *-stable-maint groups

Stephen Finucane stephenfin at redhat.com
Fri Jul 1 15:31:16 UTC 2022


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!

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




More information about the openstack-discuss mailing list