[tc][stable] Changing stable branch policy

Ghanshyam Mann gmann at ghanshyammann.com
Tue Nov 19 02:18:09 UTC 2019

 ---- On Mon, 18 Nov 2019 19:17:04 -0600 Zane Bitter <zbitter at redhat.com> wrote ----
 > On 18/11/19 5:35 pm, Ben Nemec wrote:
 > > 
 > > 
 > > On 11/18/19 4:08 PM, Matt Riedemann wrote:
 > >> On 11/18/2019 3:40 PM, Mohammed Naser wrote:
 > >>> The proposal that I had was that in mind would be for us to let teams
 > >>> self manage their own stable branches.  I think we've reached a point
 > >>> where we can trust most of our community to be familiar with the
 > >>> stable branch policy (and let teams decide for themselves what they
 > >>> believe is best for the success of their own projects).
 > >>
 > >> So for a project like nova that has a separate nova-core [1] and 
 > >> nova-stable-maint team [2] where some from [2] aren't in [1], what 
 > >> does this mean? Drop [2] and just rely on [1]? That won't work for 
 > >> those in nova-core that aren't familiar enough with the stable branch 
 > >> guidelines or simply don't care to review stable branch changes, and 
 > >> won't work for those that are in nova-stable-maint but not nova-core.
 > > 
 > > I believe the proposal is to allow the Nova team to manage 
 > > nova-stable-maint in the same way they do nova-core, not to force anyone 
 > > to drop their stable-maint team entirely.
 > I think the proposal was actually for each *-stable-maint team to manage 
 > itself. This would avoid the situation where e.g. the TC appoints a 
 > brand-new PTL and suddenly they get to make themselves a stable core, as 
 > in that case the team would still have to be bootstrapped by the 
 > stable-maint team. But it would allow those who are both closest to the 
 > project and confirmed to be familiar with the stable guidelines to make 
 > decisions about who else is ready to join that group.

I am still finding difficult to understand the change and how it will solve the current problem.

The current problem is: 
* Fewer contributors in the stable-maintenance team (core stable team and project side stable team)
   which is nothing but we have fewer contributors who understand the stable policies.

* The stable policies are not the problem so we will stick with current stable policies across all the projects. Stable 
  policies have to be maintained at single place for consistency in backports across projects.

If we are moving the stable maintenance team ownership from current stable-maintenance team to project side then,
how it will solve the issue, does it enable more contributors to understand the stable policy and extend the team?
if yes, then why it cannot happen with current model? If the project team or PTL making its core member get
more familiar with the stable policy and add as a stable core team then why it cannot happen with the current model. 

For example, if I am PTL or core of any project and finding hard to get my backport merged then I or my project team core
should review more stable branch patches and propose them in stable team core.

If we move the stable team ownership to the projects side then I think PTL is going to do the same.  Ask the team members
to understand the stable policies and do more review and then add them in stable core team. If any member know the stable
policies then directly add.

I feel that the current problem cannot be solved by moving the ownership of the team, we need to encourage more and more
developers to become stable core in existing model especially from projects who find difficulties in merging their backport.

One more thing, do we have data that how much time as avg it take to merge the backport and what all projects facing the backport merge
issue ?


 > - ZB
 > >>
 > >> [1] https://review.opendev.org/#/admin/groups/25,members
 > >> [2] https://review.opendev.org/#/admin/groups/540,members
 > >>
 > > 

More information about the openstack-discuss mailing list