On Tue, Nov 14, 2017 at 11:28 AM, Dmitry Tantsur <dtant...@redhat.com> wrote: > On 11/14/2017 05:08 PM, Bogdan Dobrelya wrote: >>>> >>>> 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. > > > I'm not assuming bad intentions, not at all. But there is a lot of involved > in a decision whether to make a backport or not. Will these people be able > to evaluate a risk of each patch? Do they have enough context on how that > release was implemented and what can break? Do they understand why feature > backports are bad? Why they should not skip (supported) releases when > backporting? > > I know a lot of very reasonable people who do not understand the things > above really well. >
I think there is more of a general "yes, but..." feel and not so much a misunderstanding or lack of understanding entirely. With my operator and PTL hats on, I'm in favor of a release cadence that is favorable for the *people* involved. It's already proven that the current model is broken or lacking in some way, simply by having these conversations. With the status quo, it's almost a death march from one release to the next, but nobody really wants to prolong that pain because this topic comes up again and again. Ideally, contributors are empowered enough to pick up the reins and deliver the changes themselves, and some are, but it's pretty damned daunting from the outside. The new contributors who want to contribute but don't see the way in, probably because we haven't said mellon, are left scratching their heads and eventually deem OpenStack as Not Ready. It's almost like a perception exists that being able to even submit a one-line patch is a gate to admittance. Unfortunately, less and less are willing to pay that toll, no matter how nice the project is on the other side. -- Best, Samuel Cassiba __________________________________________________________________________ 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