On Fri, 2022-07-01 at 16:31 +0100, Stephen Finucane 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!
i would probably delegate them to be self owned too. one thing that might be workt looking att too is the convention when stackforge was still a thign was to create 2 projects PROJECT-core and PROJECT-release and the release group was the own of the stabel branch instead of PROJECT-stable-maint the release group is mainly for pushing signed tags but it was ofthen the same group of peopel that did that as did stabel backports kuryr for example https://opendev.org/openstack/project-config/src/branch/master/gerrit/acls/o... still uses kuryr-release for stable branch merge rights as does morano. i dont see its use widely currently so maybe an non issue but i had tought at one point -release was encuraged instead of stable-maint when the neutron stadium ectra was being created. https://codesearch.opendev.org/?q=-release&i=nope&literal=nope&files=gerrit%2Facls%2Fopenstack&excludeFiles=&repos= in general i suspect that there are few usease of -release for stable for branch for porject under offcial governance.
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/21ce6c287ea33809980b2dec53915b07830c... [3] https://review.opendev.org/admin/groups/aa0f197fcfbd4fcebeff921567ed3b48cd33...