Blair, Please add #2 as a line proposal in: https://etherpad.openstack.org/p/LTS-proposal
So far it's focused on #1 Thanks, Dims On Wed, Nov 15, 2017 at 3:30 AM, Blair Bethwaite <blair.bethwa...@gmail.com> wrote: > 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 -- Davanum Srinivas :: https://twitter.com/dims __________________________________________________________________________ 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