On Tue, Nov 14, 2017 at 11:28 AM, Dmitry Tantsur email@example.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
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
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
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.