On Thu, Sep 04, 2014 at 12:57:57PM -0700, Joe Gordon wrote: > On Thu, Sep 4, 2014 at 3:24 AM, Daniel P. Berrange <berra...@redhat.com> > wrote: > > Proposal / solution > > =================== > > > > In the past Nova has spun out its volume layer to form the cinder > > project. The Neutron project started as an attempt to solve the > > networking space, and ultimately replace the nova-network. It > > is likely that the schedular will be spun out to a separate project. > > > > Now Neutron itself has grown so large and successful that it is > > considering going one step further and spinning its actual drivers > > out of tree into standalone add-on projects . I've heard on the > > grapevine that Ironic is considering similar steps for hardware > > drivers. > > > > The radical (?) solution to the nova core team bottleneck is thus to > > follow this lead and split the nova virt drivers out into separate > > projects and delegate their maintainence to new dedicated teams. > > > > - Nova becomes the home for the public APIs, RPC system, database > > persistent and the glue that ties all this together with the > > virt driver API. > > > > - Each virt driver project gets its own core team and is responsible > > for dealing with review, merge & release of their codebase. > > > > Overall I do think we need to re-think how the review burden is > distributed. That being said, this is a nice proposal but I am not sure if > it moves the review burden around enough or is the right approach. Do you > have any rough numbers on what percent of the review burden goes to virt > drivers today (how ever you want to define that statement, number of merged > patches, man hours, lines of code, number of reviews etc.). If for example > today the nova review team spends 10% of there review time on virt drivers > then I don't think this proposal will have a significant impact on the > review backlog (for nova-common).
I'm a little wary of doing too many stats on things like reviews and patches, because I fear it does not capture the full picture. Specifically we're turning away contributors before they ever get to the point of submitting reviews / patches, by rejecting their blueprints/specs. Also the difficultly of getting stuff reviewed is discouraging people even considering doing alot of work in the first place - if I had had the confidence in getting it reviewed & merged I would easily have submitted twice as much code to libvirt this cycle, but as it was I didn't even start work on most things I would have liked to. That said though, in the past 6 months we had 1385 changes merged. Of those, 437 touched at least one file in the /virt/ directory which is approximately 30%. I agree though, this proposal will not have a dramatic effect on the review backlog for the nova common code. It would probably be a small (but noticable) improvement - most of the benefit would fall on the virt drivers I expect. If we can make Nova a more productive & enjoyable place to contribute though, this should ultimately feed through into more people being involved in general and thus more resource available to nova common too. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev