<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 8 August 2016 at 18:31, Matthew Treinish <span dir="ltr"><<a href="mailto:mtreinish@kortar.org" target="_blank">mtreinish@kortar.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
</span>This argument comes up at least once a cycle and there is a reason we don't do<br>
this. When we EOL a branch all of the infrastructure for running any ci against<br>
it goes away. This means devstack support, job definitions, tempest skip checks,<br>
etc. Leaving the branch around advertises that you can still submit patches to<br>
it which you can't anymore. As a community we've very clearly said that we don't<br>
land any code without ensuring it passes tests first, and we do not maintain any<br>
of the infrastructure for doing that after an EOL.<br>
<span class=""></span><br></blockquote><div><br></div><div>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.<br><br></div><div>Given this need, what are our options?<br><br></div><div>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.<br><br></div><div>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.<br><br></div><div>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.<br><br></div><div>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?<br></div></div><br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>-- <br>Duncan Thomas</div></div></div>
</div></div>