[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