Open Stack

Well, moving this discussion is easy.  All that takes is everyone posting responses to the openstack-sig at lists.openstack.org mailing list instead of dev and ops lists.  I've cc'ed all here.  I've also added [LTS] to the subject (sorry to break all the threaders). So that the sig list knows what the general topic is.  Yeah.  It's not really a topic, but everyone is used to parsing those things, even if the mailserver sw isn't.

But, are the two groups willing to move this discussion to the sigs list?  If they are, great.  If not,  hmmm.

Anyway, here's my attempt to serve....

--Rocky

> -----Original Message-----
> From: Erik McCormick [mailto:emccormick at cirrusseven.com]
> Sent: Tuesday, November 14, 2017 4:25 PM
> To: Rochelle Grober <rochelle.grober at huawei.com>
> Cc: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev at lists.openstack.org>; openstack-oper. <openstack-
> operators at lists.openstack.org>
> Subject: Re: [Openstack-operators] [openstack-dev] Upstream LTS Releases
> 
> On Tue, Nov 14, 2017 at 4:10 PM, Rochelle Grober
> <rochelle.grober at huawei.com> wrote:
> > Folks,
> >
> > This discussion and the people interested in it seem like a perfect
> application of the SIG process.  By turning LTS into a SIG, everyone can
> discuss the issues on the SIG mailing list and the discussion shouldn't end up
> split.  If it turns into a project, great.  If a solution is found that doesn't need a
> new project, great.  Even once  there is a decision on how to move forward,
> there will still be implementation issues and enhancements, so the SIG could
> very well be long-lived.  But the important aspect of this is:  keeping the
> discussion in a place where both devs and ops can follow the whole thing and
> act on recommendations.
> >
> > Food for thought.
> >
> > --Rocky
> >
> Just to add more legs to the spider that is this thread: I think the SIG idea is a
> good one. It may evolve into a project team some day, but for now it's a
> free-for-all polluting 2 mailing lists, and multiple etherpads. How do we go
> about creating one?
> 
> -Erik
> 
> >> -----Original Message-----
> >> From: Blair Bethwaite [mailto:blair.bethwaite at gmail.com]
> >> Sent: Tuesday, November 14, 2017 8:31 AM
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> <openstack-dev at lists.openstack.org>; openstack-oper. <openstack-
> >> operators at lists.openstack.org>
> >> Subject: Re: [openstack-dev] Upstream LTS Releases
> >>
> >> Hi all - please note this conversation has been split variously
> >> across -dev and - operators.
> >>
> >> One small observation from the discussion so far is that it seems as
> >> though there are two issues being discussed under the one banner:
> >> 1) maintain old releases for longer
> >> 2) do stable releases less frequently
> >>
> >> It would be interesting to understand if the people who want longer
> >> maintenance windows would be helped by #2.
> >>
> >> On 14 November 2017 at 09:25, Doug Hellmann
> <doug at doughellmann.com>
> >> 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?
> >> >
> >> >> 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
> >>
> >>
> >>
> >> --
> >> Cheers,
> >> ~Blairo
> >>
> >>
> __________________________________________________________
> >> ________________
> >> 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
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operator
> > s