Open Stack

On Wed, Nov 20, 2019 at 7:50 PM Ben Nemec <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> 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.)

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_
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20191121/443f6511/attachment.html>