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.
The more parties to establish their 3rd party 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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
