Open Stack

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

-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando