<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 12 August 2016 at 16:09, Thierry Carrez <span dir="ltr"><<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.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>How about: 4. Take 3rd-party drivers to a separate cinder-extra-drivers<br>
repository/deliverable under the Cinder team, one that would /not/ have<br>
follows-stable-policy or follows-standard-deprecation tags ? That<br>
repository would still get core-reviewed by the Cinder team, so you<br>
would keep the centralized code review value. It would be in a single<br>
repository, so you would keep most of the "all drivers checked out in<br>
one place" benefits. But you could have a special stable branch policy<br>
there and that would also solve that other issue in the thread about<br>
removing unmaintained drivers without deprecation notices.<br>
<br>
Or is there another benefit in shipping everything inside a single<br>
repository that you didn't mention ?<br></blockquote></div><br></div><div class="gmail_extra">The development process is definitely smoother with everything in one repo. Cross repo changes (even repos under the same team, like brinck is for cinder) are painful, because you have to get the change into the 'child' repo, wait of it to merge, then wait for it to be released in some form that is usable to the parent project (e.g. a pip release), then finally you can merge the cinder change. <br><br></div><div class="gmail_extra">To turn the question around, what is the downside of loosing the tag? Are people going to suddenly stop deploying cinder? That seems rather unlikely.<br><br></div><div class="gmail_extra">Nobody has yet given a single benefit to shipping a broken driver.<br></div><div class="gmail_extra"><br><br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>-- <br>Duncan Thomas</div></div></div>
</div></div>