On 08/08/2016 12:40 PM, Duncan Thomas wrote:
On 8 August 2016 at 18:31, Matthew Treinish <mtrein...@kortar.org <mailto:mtrein...@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.
This. (2) is what I thought we were proposing from the beginning. Add a requirement for 3rd party CI from the affected vendor to pass and I think it works and benefits everyone.
-Ben Swartzlander
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. 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? -- Duncan Thomas __________________________________________________________________________ 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
__________________________________________________________________________ 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
