[tc][stable] Changing stable branch policy

Ghanshyam Mann gmann at ghanshyammann.com
Wed Nov 20 17:08:40 UTC 2019


 ---- On Wed, 20 Nov 2019 08:21:29 -0600 Matt Riedemann <mriedemos at gmail.com> wrote ----
 > On 11/20/2019 1:18 AM, Zane Bitter wrote:
 > > 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.
 > 
 > This is assuming that each project has a stable core team already, which 
 > a lot don't, that's why we get a lot of "hi I'm the PTL du jour on 
 > project X now please make me stable core even though I've never reviewed 
 > any stable branch changes before".
 > 
 > With Tony more removed these days and I myself not wanting to vet every 
 > one of these "add me to the stable core team" requests, I'm more or less 
 > OK with the proposal so that it removes me as a bottleneck. That might 
 > mean people merge things on stable branches for their projects that 
 > don't follow the guidelines but so be it. If it's a problem hopefully 
 > they'll hear about it from their consumers, but if the project is in 
 > such maintenance mode anyway that they can break the stable guidelines, 
 > then they might not have many external consumers to complain anyway. 
 > Either way I don't need to be involved.

This is the main problem going to be and I am worried about it. We had the great stable policies
with a dedicated team maintaining it well. 'great' and 'well' I am writing from the user perspective
where they get applicable backport which does not break their within-in-release upgrade.
If backport is delayed it is fine for them as compared to breaking backport.


OpenStack has a very well known problem of inconsistent APIs. Inconsistency is from
usage, interop, debug perspective. All projects define its own definition of APIs (new API, 
changes, discoverability etc) which we say it is fine because that project wants to do that way
but the user faces the problem.  We have not solved this problem yet due to various reasons.

IMO, this problem could have solved or minimized if we had "Single mandatory way to write
and maintain your API and central team to very that" from *starting* instead of project
decide its own way or recommended guidelines only. 

The same case is for stable backports, we have a "Single mandatory way to backport the changes
and central team to verify that". And due to that, OpenStack is more stable on the backports business. 
Why we are changing that?

Stable backport is more of maintaining the quality and no-break things than merging a large amount
of backports and *fast*.

-gmann

 > 
 > So sure, +1 from me on the proposal given nova can still do what it's 
 > already been doing with a specific stable maint core team ACL in Gerrit.
 > 
 > -- 
 > 
 > Thanks,
 > 
 > Matt
 > 
 > 




More information about the openstack-discuss mailing list