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


Sean Dague

OpenStack-dev mailing list

Reply via email to