-----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] +100 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 [/Rocky Grober] 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 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
