Open Stack

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.
>