Open Stack

On 08/09/2016 05:45 PM, Mike Perez wrote:
> On 19:40 Aug 08, Duncan Thomas wrote:
>> On 8 August 2016 at 18:31, Matthew Treinish <mtreinish at kortar.org> wrote:
>>
>>>
>>> This argument comes up at least once a cycle and there is a reason we
>>> don't do
>>> this. When we EOL a branch all of the infrastructure for running any ci
>>> against
>>> it goes away. This means devstack support, job definitions, tempest skip
>>> checks,
>>> etc. Leaving the branch around advertises that you can still submit
>>> patches to
>>> it which you can't anymore. As a community we've very clearly said that we
>>> don't
>>> land any code without ensuring it passes tests first, and we do not
>>> maintain any
>>> of the infrastructure for doing that after an EOL.
>>>
>>>
>> 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.
>>
>> 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.
>
> Just to set the record straight here, some Cinder core members are in favor of
> out of tree.

Mike, you must have left the midcycle by the time this topic came up. On 
the issue of out-of-tree drivers, I specifically offered this proposal 
(a community managed mechanism for distributing driver bugfix backports) 
as an compromise alternative to try to address the needs of both camps. 
Everyone who was in the room at the time (plus DuncanT who wasn't) 
agreed that if we had that (a way to deal with backports) that they 
wouldn't want drivers out of the tree anymore.

Your point of view wasn't represented so go ahead and explain why, if we 
did have a reasonable way for bugfixes to get backported to the releases 
customers actually run (leaving that mechanism unspecified for the time 
being), that you would still want the drivers out of the tree.

-Ben Swartzlander