Open Stack

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?
-- 
Kevin L. Mitchell <kevin.mitchell at rackspace.com>
Rackspace