> Ok, to turn the question around, we (the cinder team) have recognised a > definite and strong need to have somewhere for vendors to share patches on > versions of Cinder older than the stable branch policy allows. > > Given this need, what are our options? > > 1. We could do all this outside Openstack infrastructure. There are > significant downsides to doing so from organisational, maintenance, cost > etc points of view. Also means that the place vendors go for these patches > is not obvious, and the process for getting patches in is not standard. And if some people have 2 or more different storages, they might need to run separate Cinder processes, because the vendors' stable tree diverge and cannot easily be merged again.
> 2. We could have something not named 'stable' that has looser rules than > stable branches,, maybe just pep8 / unit / cinder in-tree tests. No > devstack. +1 from me. Name it "long-term-driver-only-updates" or so ;) > 3. We go with the Neutron model and take drivers out of tree. This is not > something the cinder core team are in favour of - we see significant value > in the code review that drivers currently get - the code quality > improvements between when a driver is submitted and when it is merged are > sometimes very significant. Also, taking the code out of tree makes it > difficult to get all the drivers checked out in one place to analyse e.g. > how a certain driver call is implemented across all the drivers, when > reasoning or making changes to core code. -1 > Given we've identified a clear need, and have repeated rejected one > solution (take drivers out of tree - it has been discussed at every summit > and midcycle for 3+ cycles), what positive suggestions can people make? Number 2 - a centralized branch (ie. in openstack.org) that *only* takes driver updates (and doesn't need CI). If a driver is broken, too bad for that vendor - must have been the last driver update, as the Cinder code didn't change since EOL... __________________________________________________________________________ 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