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.

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

Reply via email to