Open Stack

Duncan Thomas wrote:
> [...]
> 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.
> 
> 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.
> 
> 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.

How about: 4. Take 3rd-party drivers to a separate cinder-extra-drivers
repository/deliverable under the Cinder team, one that would /not/ have
follows-stable-policy or follows-standard-deprecation tags ? That
repository would still get core-reviewed by the Cinder team, so you
would keep the centralized code review value. It would be in a single
repository, so you would keep most of the "all drivers checked out in
one place" benefits. But you could have a special stable branch policy
there and that would also solve that other issue in the thread about
removing unmaintained drivers without deprecation notices.

Or is there another benefit in shipping everything inside a single
repository that you didn't mention ?

-- 
Thierry Carrez (ttx)