On Aug 29, 2014, at 5:07 AM, Thierry Carrez <thie...@openstack.org> wrote:
> 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. 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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
