Open Stack

On Aug 29, 2014, at 5:07 AM, Thierry Carrez <thierry at openstack.org> wrote:

> Joe Gordon wrote:
>> On Thu, Aug 28, 2014 at 2:43 PM, Alan Kavanagh
>> <alan.kavanagh at ericsson.com <mailto:alan.kavanagh at ericsson.com>> wrote:
>> 
>>>    I share Donald's points here, I believe what would help is to
>>>    clearly describe in the Wiki the process and workflow for the BP
>>>    approval process and build in this process how to deal with
>>>    discrepancies/disagreements and build timeframes for each stage and
>>>    process of appeal etc.
>>>    The current process would benefit from some fine tuning and helping
>>>    to build safe guards and time limits/deadlines so folks can expect
>>>    responses within a reasonable time and not be left waiting in the cold.
>> 
>> This is a resource problem, the nova team simply does not have enough
>> people doing enough reviews to make this possible. 
> 
> I think Nova lacks core reviewers more than it lacks reviewers, though.
> Just looking at the ratio of core developers vs. patchsets proposed,
> it's pretty clear that the core team is too small:
> 
> Nova: 750 patchsets/month for 21 core = 36
> Heat: 230/14 = 16
> Swift: 50/16 = 3
> 
> Neutron has the same issue (550/14 = 39). I think above 20, you have a
> dysfunctional setup. No amount of process, spec, or runway will solve
> that fundamental issue.
> 
> The problem is, you can't just add core reviewers, they have to actually
> understand enough of the code base to be trusted with that +2 power. All
> potential candidates are probably already in. In Nova, the code base is
> so big it's difficult to find people that know enough of it. In Neutron,
> the contributors are often focused on subsections of the code base so
> they are not really interested in learning enough of the rest. That
> makes the pool of core candidates quite dry.
> 
> I fear the only solution is smaller groups being experts on smaller
> codebases. There is less to review, and more candidates that are likely
> to be experts in this limited area.
> 
> Applied to Nova, that means modularization -- having strong internal
> interfaces and trusting subteams to +2 the code they are experts on.
> Maybe VMWare driver people should just +2 VMware-related code. We've had
> that discussion before, and I know there is a dangerous potential
> quality slope there -- I just fail to see any other solution to bring
> that 750/21=36 figure down to a bearable level, before we burn out all
> of the Nova core team.

Besides making packaging and testing easier, one of the reasons Oslo uses a separate git repo for each of our libraries is to allow this sort of specialization. We have a core group with +2 across all of the libraries, and we have some team members who only have +2 on one or two specific libraries where they focus their attention.

Doug

> 
> -- 
> Thierry Carrez (ttx)
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev