Pardon me for cutting out most of the discussion. I'd like to summarize a bit here and make a proposal.
Issues: * Driver and Plugin writers for Nova (and other Core OpenStack projects) have a different development focus than core developers which can create both delays in getting submitted code reviewed and tensions between to two camps. * It is in OpenStack's best interests to have these driver/plugin writers participating in OpenStack development as their contributions help make OpenStack a more relevant and compelling set of products in the Cloud space * Delays of reviews are painful to driver writers causing extra branching, lots of duplicated work, etc. * Nova Core reviewers are overworked and are less versed on the driver/plugin code, architecture, issues which makes them a little averse to performing reviews on these patches * [developers|reviewers] aren't appreciated * Tempers flair Proposed solution: There have been a couple of solutions proposed. I'm presenting a merged/hybrid solution that may work * Create a new repository for the extra drivers: o Keep kvm and Xenapi in the Nova project as "reference" drivers o openstack/nova-extra-drivers (proposed by rbryant) o Have all drivers other than reference drivers in the extra-drivers project until they meet the maturity of the ones in Nova o The core reviewers for nova-extra-drivers will come from its developer pool. As Alessandro pointed out, all the driver developers have more in common with each other than core Nova, so they should be able to do a better job of reviewing these patches than Nova core. Plus, this might create some synergy between different drivers that will result in more commonalities across drivers and better stability. This also reduces the workloads on both Nova Core reviewers and the driver developers/core reviewers. o If you don't feel comfortable with the last bullet, have the Nova core reviewers do the final approval, but only for the obvious "does this code meet our standards?" The proposed solution focuses the strengths of the different developers in their strong areas. Everyone will still have to stretch to do reviews and now there is a possibility that the developers that best understand the drivers might be able to advance the state of the drivers by sharing their expertise amongst each other. The proposal also offloads some of the workload for Nova Core reviewers and places it where it is best handled. And, no more sniping about participation. The driver developers will participate more because their vested interests are communal to the project they are now in. Maybe the integration of tests, etc will even happen faster and expand coverage faster. And by the way, the statistics on participation are just that: statistics. If you look at rbryant's numbers, they are different from Stackalytics which are different from Launchpad which are different from review.openstack.org. And as and fYI. Guess what? Anyone working on a branch, such as stable (which promotes the commercial viability of OpenStack) gets ignored for their contributions once the branch has happened. At least on Stackalytics. I don't know about rbryant's numbers. --Rocky Grober
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
