Open Stack

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> 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
>   >
>   >
> 
>