Joe Gordon wrote: > On Thu, Aug 28, 2014 at 2:43 PM, Alan Kavanagh > <alan.kavan...@ericsson.com <mailto:alan.kavan...@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) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
