On Tue, Nov 14, 2017 at 4:10 PM, Rochelle Grober <rochelle.gro...@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.bethwa...@gmail.com] >> Sent: Tuesday, November 14, 2017 8:31 AM >> To: OpenStack Development Mailing List (not for usage questions) >> <openstack-...@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-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators