Open Stack

Le 05/09/2014 12:48, Sean Dague a écrit :
> On 09/05/2014 03:02 AM, Sylvain Bauza wrote:
>> Le 05/09/2014 01:22, Michael Still a écrit :
>>> On Thu, Sep 4, 2014 at 5:24 AM, Daniel P. Berrange
>>> <berrange at redhat.com> wrote:
>>>
>>> [Heavy snipping because of length]
>>>
>>>> The radical (?) solution to the nova core team bottleneck is thus to
>>>> follow this lead and split the nova virt drivers out into separate
>>>> projects and delegate their maintainence to new dedicated teams.
>>>>
>>>>    - Nova becomes the home for the public APIs, RPC system, database
>>>>      persistent and the glue that ties all this together with the
>>>>      virt driver API.
>>>>
>>>>    - Each virt driver project gets its own core team and is responsible
>>>>      for dealing with review, merge & release of their codebase.
>>> I think this is the crux of the matter. We're not doing a great job of
>>> landing code at the moment, because we can't keep up with the review
>>> workload.
>>>
>>> So far we've had two proposals mooted:
>>>
>>>    - slots / runways, where we try to rate limit the number of things
>>> we're trying to review at once to maintain focus
>>>    - splitting all the virt drivers out of the nova tree
>> Ahem, IIRC, there is a third proposal for Kilo :
>>   - create subteam's half-cores responsible for reviewing patch's
>> iterations and send to cores approvals requests once they consider the
>> patch enough stable for it.
>>
>> As I explained, it would allow to free up reviewing time for cores
>> without loosing the control over what is being merged.
> I don't really understand how the half core idea works outside of a math
> equation, because the point is in core is to have trust over the
> judgement of your fellow core members so that they can land code when
> you aren't looking. I'm not sure how I manage to build up half trust in
> someone any quicker.

Well, this thread is becoming huge so that's becoming hard to follow all 
the discussion but I explained the idea elsewhere. Let me just provide 
it here too :
The idea is *not* to land patches by the halfcores. Core team will still 
be fully responsible for approving patches. The main problem in Nova is 
that cores are spending lots of time because they review each iteration 
of a patch, and also have to look at if a patch is good or not.

That's really time consuming, and for most of the time, quite 
frustrating as it requires to follow the patch's life, so there are high 
risks that your core attention is becoming distracted over the life of 
the patch.

Here, the idea is to reduce dramatically this time by having teams 
dedicated to specific areas (as it's already done anyway for the various 
majority of reviewers) who could on their own take time for reviewing 
all the iterations. Of course, that doesn't mean cores would loose the 
possibility to specifically follow a patch and bypass the halfcores, 
that's just for helping them if they're overwhelmed.

About the question of trusting cores or halfcores, I can just say that 
Nova team is anyway needing to grow up or divide it so the trusting 
delegation has to be real anyway.

This whole process is IMHO very encouraging for newcomers because that 
creates dedicated teams that could help them to improve their changes, 
and not waiting 2 months for getting a -1 and a frank reply.


As I said elsewhere, I dislike the slots proposal because it sends to 
the developers the message that the price to pay for contributing to 
Nova is increasing. Again, that's not because you're prioritizing that 
you increase your velocity, that's 2 distinct subjects.

-Sylvain


> 	-Sean
>