Open Stack

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 <berrange at 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 [4]. 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 :|