<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jan 4, 2014 at 8:02 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 01/03/2014 08:27 PM, Robert Collins wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On 4 January 2014 08:44, Doug Hellmann <<a href="mailto:doug.hellmann@dreamhost.com" target="_blank">doug.hellmann@dreamhost.com</a>> wrote:<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It seems safer to gate changes to libraries against the apps' trunk (to<br>
avoid making backwards-incompatible changes), and then gate changes to the<br>
apps against the released libraries (to ensure they work with something<br>
available to be packaged by the distros). There are lots and lots of version<br>
numbers available to us, so I see no problem with releasing new versions of<br>
libraries frequently.<br>
</blockquote></div></blockquote>
<br>
So we used to do that the apps against release libraries. And the result was more and more full day gate breaks. We did 2 consecutive ones in 2 weeks.<br>
<br>
Basically, once you get to be a certain level of coupled in OpenStack we can no longer let you manage your own requirements file. We need a global lever on it. Because people were doing it wrong, and slowly (we could go through specific examples about how bad this was. This was a top issue at nearly every summit I'd been at going back to Essex.<br>
<br>
Some reading from the break times:<br>
* <a href="http://lists.openstack.org/pipermail/openstack-dev/2013-July/011660.html" target="_blank">http://lists.openstack.org/<u></u>pipermail/openstack-dev/2013-<u></u>July/011660.html</a><br>
* <a href="http://lists.openstack.org/pipermail/openstack-dev/2013-July/011708.html" target="_blank">http://lists.openstack.org/<u></u>pipermail/openstack-dev/2013-<u></u>July/011708.html</a><br>
* <a href="http://lists.openstack.org/pipermail/openstack-dev/2013-July/012342.html" target="_blank">http://lists.openstack.org/<u></u>pipermail/openstack-dev/2013-<u></u>July/012342.html</a><br>
<br>
(It was about 14 days to resolve the python client issue, there was a django issue around the same time that never made it to the list, as we did it all under fire in IRC)<br>
<br>
And we have a solution now. Which is one list of requirements that we can test everything with, that we can propose requirements updates speculatively, and see what works and what doesn't. And *after* we know they work, we propose the changes back into the projects, now automatically. </blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I do see the issue Sean is pointing at, which is that we have to fix<br>
the libraries first and then the things that use them. OTOH thats<br>
normal in the software world, I don't see anything unique about it.<br>
</blockquote>
<br></div>
Well, as the person that normally gets stuck figuring this out when .eu has been gate blocked for a day, and I'm one of the first people up on the east coast, I find the normal state of affairs unsatisfying. :)<br></blockquote>
<div><br></div><div><div class="gmail_default" style="font-size:small">I appreciate you going through the details with me. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">
As I said at the beginning, I'm not opposed to bringing taskflow into the oslo program at all -- and we can still do that, if Josh wants to, retaining the existing core review team, permissions, etc. -- but since we plan to release more libraries over time I want to make sure that we're set up to handle cases like this where we have access to the developers and source for a library, but don't call it an "openstack" library.</div>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I also think that what we are basically dealing with is the classical N^2 comms problem. With N git trees that we need to all get working together, this gets exponentially more difficult over time. Which is why we created the integrated gate and the global requirements lever.<br>
<br>
Another solution would be reduce the number of OpenStack git trees to make N^2 more manageable, and let us with single commits affect multiple components. But that's not the direction we've taken.</blockquote><div>
<br></div><div><div class="gmail_default" style="font-size:small">The global requirements syncing seems to have fixed the issue for apps, although it just occurred to me that I'm not sure we check that the requirements lists are the same when we cut a release. Do we do that already?</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Doug</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im HOEnZb"><br>
<br>
-Sean<br>
<br>
-- <br>
Sean Dague<br>
Samsung Research America<br>
<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a> / <a href="mailto:sean.dague@samsung.com" target="_blank">sean.dague@samsung.com</a><br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br></div><div class="HOEnZb"><div class="h5">
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>