This seems a fair way of doing it. Gives users and developers a fair warning.
If its not tested, because we will keep breaking it by accident, and thats not fair on anyone, so those drivers shouldn't be in the main tree I wonder if we should requiring a certain level of testing or unit testing? Like % coverage, or start VM, attach volume, delete VM? Either way, this seems a good step forward. John On 10 July 2013 15:33, Russell Bryant <rbry...@redhat.com> wrote: > On 07/10/2013 08:05 AM, Joe Gordon wrote: >> >> >> >> On Tue, Jul 2, 2013 at 7:38 PM, Russell Bryant <rbry...@redhat.com >> <mailto:rbry...@redhat.com>> wrote: >> >> Greetings, >> >> Nova includes various compute drivers today, but the test coverage they >> receive varies quite a bit. This is documented on the following wiki >> page. The drivers are broken up into groups A, B, and C. >> >> https://wiki.openstack.org/wiki/HypervisorSupportMatrix >> >> We have two new compute drivers in the queue for Havana: docker [1] and >> z/vm [2]. I'd like to propose as a piece of criteria for inclusion that >> new drivers go into groups A or B. >> >> Further, I would like to see *all* drivers move into groups A or B by >> the release of Icehouse. I've been told that this is already in the >> works for VMware and baremetal, at least. >> >> >> And if a driver doesn't go into group A or B by Icehouse? Do we put >> clear warnings in the release notes that they are 'use at your own >> risk.' Perhaps if drivers stay in C by the end of Icehouse Development >> we remove them, as we have no way of guaranteeing they work and shipping >> broken code looks bad. > > Yes, removing them is what I had in mind. > > -- > Russell Bryant > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
