On Wed, Sep 10, 2014 at 3:44 AM, Daniel P. Berrange <berra...@redhat.com> wrote: > 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. > I would be cautious around sub-teams. Our experience in Neutron has been that we do a very good job of setting up sub-teams, but a terrible job at deciding when they should be spun-down and folded back in. Because in a lot of cases, a sub-team's existance should be for a short period of time. The other problem is that sub-teams can tend to wander away from the broader team, making it harder for their work to be integrated back into the whole. All of this is to say that sub-teams require coordination and lots of communication, and should be carefully watched, groomed, and culled when necessary.
Thanks, Kyle > 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
