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

Sean Mooney smooney at redhat.com
Fri Jul 1 16:15:36 UTC 2022

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/openstack/kuryr.config
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.


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/21ce6c287ea33809980b2dec53915b07830cdb11
> [3] https://review.opendev.org/admin/groups/aa0f197fcfbd4fcebeff921567ed3b48cd330a4c

More information about the openstack-discuss mailing list