Open Stack

On Tue, Nov 14, 2017 at 11:25:03AM -0500, Doug Hellmann wrote:
> Excerpts from Bogdan Dobrelya's message of 2017-11-14 17:08:31 +0100:
> > >> The concept, in general, is to create a new set of cores from these
> > >> groups, and use 3rd party CI to validate patches. There are lots of
> > >> details to be worked out yet, but our amazing UC (User Committee) will
> > >> be begin working out the details.
> > > 
> > > What is the most worrying is the exact "take over" process. Does it mean that 
> > > the teams will give away the +2 power to a different team? Or will our (small) 
> > > stable teams still be responsible for landing changes? If so, will they have to 
> > > learn how to debug 3rd party CI jobs?
> > > 
> > > Generally, I'm scared of both overloading the teams and losing the control over 
> > > quality at the same time :) Probably the final proposal will clarify it..
> > 
> > The quality of backported fixes is expected to be a direct (and only?) 
> > interest of those new teams of new cores, coming from users and 
> > operators and vendors. The more parties to establish their 3rd party 
> 
> We have an unhealthy focus on "3rd party" jobs in this discussion. We
> should not assume that they are needed or will be present. They may be,
> but we shouldn't build policy around the assumption that they will. Why
> would we have third-party jobs on an old branch that we don't have on
> master, for instance?
> 
I get the feeling more people are comfortable contributing to their own 3rd
party CI then upstream openstack CI systems.  Either because they don't have the
time or don't understand how it works. I agree with Doug, for this to work, I
think we need to have a health amount of people helping keep the CI systems
running upstream, then depending on 3rd party CI downstream.

As a comment, I think getting involved in the openstack-stablemaint team will be
a good first step towards the goals people are interested in here. I'm happy to
help work with others, and I'm taking tonyb up on his offer to start helping too
:)

> > checking jobs, the better proposed changes communicated, which directly 
> > affects the quality in the end. I also suppose, contributors from ops 
> > world will likely be only struggling to see things getting fixed, and 
> > not new features adopted by legacy deployments they're used to maintain. 
> > So in theory, this works and as a mainstream developer and maintainer, 
> > you need no to fear of losing control over LTS code :)
> > 
> > Another question is how to not block all on each over, and not push 
> > contributors away when things are getting awry, jobs failing and merging 
> > is blocked for a long time, or there is no consensus reached in a code 
> > review. I propose the LTS policy to enforce CI jobs be non-voting, as a 
> > first step on that way, and giving every LTS team member a core rights 
> > maybe? Not sure if that works though.
> 
> I'm not sure what change you're proposing for CI jobs and their voting
> status. Do you mean we should make the jobs non-voting as soon as the
> branch passes out of the stable support period?
> 
> Regarding the review team, anyone on the review team for a branch
> that goes out of stable support will need to have +2 rights in that
> branch. Otherwise there's no point in saying that they're maintaining
> the branch.
> 
> Doug
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev