Open Stack

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.

-- 
Thierry Carrez (ttx)