Duncan Thomas wrote: > Given the options, I'd agree with Sean and John that removing the tag is > a far lesser evil than changing our policy.
Agree that the tag should be removed. The Cinder core certainly follows standard deprecation policy, but the Cinder drivers are not. > If we leave broken drivers in the tree, the end user (operator) is no > better off - the thing they evaluated won't work - but it will be harder > to tell why. The storage vendor won't suffer the pressure that comes > from driver removal, so will have less incentive to fix their driver > (there's enough examples of the threat of driver removal causing the > immediate fix of things that have remained broken for months that we > know, for certain that the policy works). I agree that leaving broken drivers in tree is not significantly better from an operational perspective. But I think the best operational experience would be to have an idea of how much risk you expose yourself when you pick a driver, and have a number of them that are actually /covered/ by the standard deprecation policy. So ideally there would be a number of in-tree drivers (on which the Cinder team would apply the standard deprecation policy), and a separate repository for 3rd-party drivers that can be removed at any time (and which would /not/ have the follows-standard-deprecation-policy tag). I understand that this kind of reorganization is a bit painful for little (developer-side) gain, but I think it would provide the most useful information to our users and therefore the best operational experience... -- Thierry Carrez (ttx) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
