-----Original Message-----
From: Daniel P. Berrange [mailto:berra...@redhat.com] 
Sent: Wednesday, September 10, 2014 1:45 AM

On Tue, Sep 09, 2014 at 05:14:43PM -0700, Stefano Maffulli wrote:
> > To me, this means you don't really want a sin bin where you dump
> > drivers and tell them not to come out until they're fit to be
> > reviewed by the core; You want a trusted driver community which does
> > its own reviews and means the core doesn't have to review them.
> I think we're going somewhere here, based on your comment and other's:
> we may achieve some result if we empower a new set of people to manage
> drivers, keeping them in the same repositories where they are now. This
> new set of people may not be the current core reviewers but other with
> different skillsets and more capable of understanding the driver's
> ecosystem, needs, motivations, etc.
> I have the impression this idea has been circling around for a while but
> for some reason or another (like lack of capabilities in gerrit and
> other reasons) we never tried to implement it. Maybe it's time to think
> about an implementation. We have been thinking about mentors
> https://wiki.openstack.org/wiki/Mentors, maybe that's a way to go?
> Sub-team with +1.5 scoring capabilities?

I think that setting up subteams is neccessary to stop us imploding but
I don't think it is enough. As long as we have one repo we're forever
going to have conflict & contention in deciding which features to accept,
which is a big factor in problems today. I favour the strong split of the
drivers into separate repositories to remove the contente between the
teams as much as is practical.

[Rocky Grober]  

There is a huge benefit to getting the drivers into separate repositories.  
Once the APIs/interfaces in Nova are clean enough to support the move, they 
will stay cleaner than if the drivers are in the same repository.  And the 
subteams will ensure that the drivers are to their level of quality.  The CI 
system will be easier to manage with thirdparty CIs for each of the drivers.  
And to get changes into Nova Core, the subteams will need to cooperate, as any 
core change that affects one driver will most likely affect others, so it will 
be in the subteams' best interests to keep the driver/core APIs clean and free 
of special cases.

>From Kyle's later mail:
>I think that is absolutely the case: sub-team leaders need to be vetted based 
>on their upstream communication skills. I also think what we're looking at in 
>Neutron is giving sub-teams a shelf-life, and spinning them down rather than 
>letting them live long-term, lose focus, and wander aimlessly.

This is also a very important point that I'd like to expand on.  The subteams 
really should form a "drivers" team composed of each subteams' PTLs.  This 
drivers team would be the interface to Nova Core and would need those upstream 
communications skills.  This team could also be the place Nova Core/Driver API 
changes get discussed and finalized from the drivers' perspective.  Maybe the 
Drivers PTL team should even start with electing a Nova Core from its PTLs as 
the Drivers team lead.  This team would also be the perfect place for Nova PTL 
and team to work with Drivers teams to collaborate on specs and issues.

Unlike in Neutron, the subteams wouldn't roll back into the Nova core, as their 
charter/purpose will continue to develop as hypervisors, containers, bare metal 
and other new virtual control planes develop.  Getting these teams right will 
mean more agility, higher quality and better consistency within the Nova 
ecosystem.  The drivers team should become strong partners with Nova core in 
allowing Nova to innovate more quickly while addressing technical debt to 
increase quality around the Nova/drivers interactions.

[/Rocky Grober]

|: 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

OpenStack-dev mailing list

Reply via email to