> -----Original Message-----
> From: Sean Dague [mailto:s...@dague.net]
> Sent: 05 September 2014 11:49
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [nova] Averting the Nova crisis by splitting out
> virt drivers
> 
> On 09/05/2014 03:02 AM, Sylvain Bauza wrote:
> >
> >
> > 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
> 
You seem to be looking at a model Sean where trust is purely binary - you’re 
either trusted to know about all of Nova or not trusted at all.  

What Sylvain is proposing (I think) is something more akin to having folks that 
are trusted in some areas of the system and/or trusted to be right enough of 
the time that their reviewing skills take a significant part of the burden of 
the core reviewers.    That kind of incremental development of trust feels like 
a fairly natural model me.    Its some way between the full divide and rule 
approach of splitting out various components (which doesn't feel like a short 
term solution) and the blanket approach of adding more cores.

Making it easier to incrementally grant trust, and having the processes and 
will to remove it if its seen to be misused feels to me like it has to be part 
of the solution to breaking out of the "we need more people we trust, but we 
don’t feel comfortable trusting more than N people at any one time".  Sometimes 
you have to give people a chance in small, well defined and controlled steps.

Phil

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to