Open Stack

On 11/21/19 7:46 AM, Erno Kuvaja wrote:
> On Wed, Nov 20, 2019 at 7:50 PM Ben Nemec <openstack at nemebean.com 
> <mailto:openstack at nemebean.com>> wrote:
> 
> 
> 
>     On 11/20/19 11:08 AM, Ghanshyam Mann wrote:
>      >   ---- On Wed, 20 Nov 2019 08:21:29 -0600 Matt Riedemann
>     <mriedemos at gmail.com <mailto: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.
> 
>     Is it? Important backports being delayed due to lack of stable
>     reviewers
>     still leaves consumers with a broken piece of software.
> 
>     I also think this is a bit of a false dichotomy. Nobody is suggesting
>     that we start approving backports willy-nilly, just that we lower the
>     barrier to entry for people who want to help with stable branch
>     reviews.
>     I would hope we can trust our teams to be responsible with their
>     stable-maint list and not just start handing out +2 to anyone with a
>     pulse. If not, I think we have a bigger problem, but let's cross that
>     bridge if and when we come to it.
> 
>      >
>      >
>      > 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?
> 
>     This does not change the stable policy, and the existence of
>     project-specific stable-maint teams means there was never a single
>     central team reviewing all stable backports. Even if there had been,
>     it's pretty clear that model doesn't work given the staffing
>     constraints
>     we are facing in almost every area, and which are only going to get
>     worse after this cycle.
> 
>     The proposal removes some inflexible process that currently prevents
>     contributors from becoming stable maintainers, it does _not_ mean we
>     stop expecting stable maintainers to understand the stable policy.
> 
>      >
>      > 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
>      >   >
>      >   >
>      >
>      >
> 
> 
> Sounds like we're back in a spot where Stable Maintenance team probably 
> shouldn't be a thing then and I think this time around I do agree.
> 
> Perhaps we should just discontinue the Stable Maintenance group all 
> together (not just as part of stable reviewers and moderators of in 
> project stable maintenance groups) and subject our Stable Branch 
> policies and guidelines directly under governance. Obviously unless 
> we're planning to put the bolt on TCs head as well being unscalable 
> group most don't care about. (We might even get some folks who care 
> about stable branches and releases to be interested about TC.)

I don't have a strong opinion about this, other than that it's important 
to have someone people can go to for questions about stable backports. 
If that's a stable team or some other entity is irrelevant to me, but 
unusual situations do come up and the stable team was extremely helpful 
with the one I asked about recently[0].

0: 
http://lists.openstack.org/pipermail/openstack-discuss/2019-October/009984.html

> 
> If nothing else, the good part of this discussion is the message that we 
> have amazing flood of people being interested to join the stable 
> maintenance to overwhelm the current Stable Maint team with requests. So 
> lets remove the clearly toxic vetting process and get these people to work!
> 
> - jokke_