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 > -----Original Message----- > From: Blair Bethwaite [mailto:blair.bethwa...@gmail.com] > Sent: Tuesday, November 14, 2017 8:31 AM > To: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@lists.openstack.org>; openstack-oper. <openstack- > operat...@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 <d...@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-requ...@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- > requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
