Open Stack

 ---- On Wed, 20 Nov 2019 01:18:39 -0600 Zane Bitter <zbitter at redhat.com> wrote ----
 > On 18/11/19 9:18 pm, Ghanshyam Mann wrote:
 > >   ---- 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?
 > 
 > Yes.
 > 
 > > if yes, then why it cannot happen with current model?
 > 
 > Because the core stable team is necessarily not as familiar with the 
 > review/backport history of contributors in every project as the 
 > individual project stable team is with contributors in each project.
 > 
 > > 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.
 > 
 > I have tried that with only very limited success.
 > 
 > > 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.
 > 
 > You make it sound like that's not a good thing?

This is a good thing but I am saying why it cannot happen in the current model? If I am PTL of x project then and find hard to merge
my backport I can ask for stable team volunteer from my core/active contributors and then they learn/onboard to stable team.

 >  
 > > 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.
 > 
 > In my experience at least there's no shortage of people willing to do 
 > the work, but there is a severe shortage of people willing to do the 
 > work of climbing over the bar to get permission to do the work.
 > 
 > The position espoused by Tony and Matt at least is that those shouldn't 
 > be different things, and in principle that's correct, but in practice 
 > they are. Humans are weird.

humm, I feel same can exist in new model also. Not all existing core going to become the
stable core for that project. PTL or someone has to filter out the list and add the new members
to list where same issue can happen.

I feel if stable policies are going to be the same then we should not change the model which is working fine
from user perspective.

-gmann


 > 
 > > 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 ?
 > > 
 > > -gmann
 > > 
 > >   >
 > >   > - ZB
 > >   >
 > >   > >>
 > >   > >> [1] https://review.opendev.org/#/admin/groups/25,members
 > >   > >> [2] https://review.opendev.org/#/admin/groups/540,members
 > >   > >>
 > >   > >
 > >   >
 > >   >
 > >   >
 > > 
 > 
 >