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 <[email protected]> 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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
