<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 30, 2015, at 11:22 PM, Kevin Benton <<a href="mailto:blak111@gmail.com" class="">blak111@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi,<div class=""><br class=""></div><div class="">We have had at least two breaking changes merge this week for out-of-tree drivers/plugins. These are just the two I noticed that broke the Big Switch CI (the one I keep an eye on since I had set it up):</div><div class=""><br class=""></div><div class="">1. Removed test_lib that changes config files. <a href="https://review.openstack.org/#/c/196583/" class="">https://review.openstack.org/#/c/196583/</a><br clear="all" class=""></div><div class="">2. Removed the loopingcall common util with no deprecation cycle or announcement. <a href="https://review.openstack.org/#/c/192999/" class="">https://review.openstack.org/#/c/192999/</a><br class=""></div><div class=""><div class=""><br class=""></div><div class="">I proposed a revert for 1 that merged, but I don't particularly want to keep fighting this. What is our current policy on this? Just change whatever we want and tell plugin maintainers this is just the way things work?</div></div></div></div></blockquote><div><br class=""></div><div>So, this is a big hairy bit of suck right now. We expected some of this fallout with the services split and plugin decomp (in fact, we counted on it to move this ball forward), and we had adopted these guideilnes:</div><div><br class=""></div><div>1. Other repos should not rely on oslo-incubated modules. (neutron/openstack/…)</div><div>2. Other repos should not rely on neutron’s test infrastructure. (neutron/tests/…)</div><div>3. For changes in any other area, they should be additive, or have a backwards compatibility shim or a big warning notice (the last being the suckiest answer.)</div><div>4. When we start getting “stable” interfaces in neutron/lib/…, which has the proviso of NO breaking changes without a shim or deprecation cycle, we get rid of restriction #3.</div><div><br class=""></div><div>We’ve been regularly merging code that breaks #3 and we have plugins that use code from #1 and #2 today.</div><div><br class=""></div><div>IMO, the core review team needs to be aware that neutron is now a library, and refactors and gratuitous cleanups have a pretty hefty cost. Especially in Liberty, be careful.</div><div><br class=""></div><div>Thanks,</div><div>doug</div><div><br class=""></div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><br class=""></div>-- <br class=""><div class="gmail_signature"><div class="">Kevin Benton</div></div>
</div></div>
__________________________________________________________________________<br class="">OpenStack Development Mailing List (not for usage questions)<br class="">Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" class="">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class=""></div></blockquote></div><br class=""></body></html>