[all][tc][gerrit] Ownership of *-stable-maint groups
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/21ce6c287ea33809980b2dec53915b07830c... [3] https://review.opendev.org/admin/groups/aa0f197fcfbd4fcebeff921567ed3b48cd33...
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...
On 2022-07-01 17:15:36 +0100 (+0100), Sean Mooney wrote: [...]
i had tought at one point -release was encuraged instead of stable-maint when the neutron stadium ectra was being created. [...]
Perhaps lost to the annals of time, but these were the -drivers groups, most of which got renamed to -release. -- Jeremy Stanley
---- On Fri, 01 Jul 2022 10:31:16 -0500 Stephen Finucane <stephenfin@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.ht... 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/21ce6c287ea33809980b2dec53915b07830c... [3] https://review.opendev.org/admin/groups/aa0f197fcfbd4fcebeff921567ed3b48cd33...
On 2022-07-01 11:17:26 -0500 (-0500), Ghanshyam Mann wrote: [...]
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.ht...
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. [...]
Except that they aren't, at least not in any practical sense, and that's what was missed. Sounds like I'm free to make the groups in Gerrit all be self-owned? -- Jeremy Stanley
---- On Fri, 01 Jul 2022 12:41:57 -0500 Jeremy Stanley <fungi@yuggoth.org> wrote ---
On 2022-07-01 11:17:26 -0500 (-0500), Ghanshyam Mann wrote: [...]
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.ht...
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. [...]
Except that they aren't, at least not in any practical sense, and that's what was missed. Sounds like I'm free to make the groups in Gerrit all be self-owned?
Yes, please. I think we thought there is no such restriction in those group untill Stephen brought this here. ---- On Fri, 01 Jul 2022 12:41:57 -0500 Jeremy Stanley <fungi@yuggoth.org> wrote ---
On 2022-07-01 11:17:26 -0500 (-0500), Ghanshyam Mann wrote: [...]
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.ht...
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. [...]
Except that they aren't, at least not in any practical sense, and that's what was missed. Sounds like I'm free to make the groups in Gerrit all be self-owned?
Yes, please. I think we thought there is no such restriction in those group until Stephen brought this here. -gmann
-- Jeremy Stanley
-gmann
-- Jeremy Stanley
On 2022-07-01 16:31:16 +0100 (+0100), Stephen Finucane wrote: [...]
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 [...]
I've gone through and switched all 18 of these to self-owned just now, as requested in Ghanshyam's reply. Please let me know if you find any others which need similar treatment. -- Jeremy Stanley
participants (4)
-
Ghanshyam Mann
-
Jeremy Stanley
-
Sean Mooney
-
Stephen Finucane