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.

Samuel Cassiba

OpenStack Development Mailing List (not for usage questions)

Reply via email to