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-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
