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.mitch...@rackspace.com> Rackspace _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
