On Fri, Sep 05, 2014 at 10:25:09AM -0500, Kevin L. Mitchell wrote: > On Fri, 2014-09-05 at 10:26 +0100, Daniel P. Berrange wrote: > > > 2. Removal of drivers other than the reference implementation for each > > > project could be the healthiest option > > > a. Requires transparent, public, automated 3'rd party CI > > > b. Requires a TRUE plugin architecture and mentality > > > c. Requires a stable and well defined API > > > > As mentioned in the original mail I don't want to see a situation where > > we end up with some drivers in tree and others out of tree as it sets up > > bad dynamics within the project. Those out of tree will always have the > > impression of being second class citizens and thus there will be constant > > pressure to accept drivers back into tree. The so called 'reference' > > driver that stayed in tree would also continue to be penalized in the > > way it is today, and so its development would be disadvantaged compared > > to the out of tree drivers. > > I have one quibble with the notion of "not even one" driver in core: I > think it is probably useful to include a dummy, do-nothing driver that > can be used for in-tree functional tests and as an example to point > those interested in writing a driver. Then, the "second-class citizen" > is the one actually in the tree :) Beyond that, I agree with this > proposal: it has never made sense to me that *all* drivers live in the > tree, and it actually offends my sense of organization to have the tree > so cluttered; we split functions when they get too big, we split modules > when they get too big, and we create subdirectories when packages get > too big, so why not split repos when they get too big?
Oh sure, having a "fake virt" driver in tree is fine and indeed desirable for the reasons you mention. I was exclusively thinking about the real virt drivers in my earlier statement. 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
