<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 3, 2014 at 3:13 PM, 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 02:44 PM, Doug Hellmann wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<br>
<br>
On Fri, Jan 3, 2014 at 12:45 PM, Joshua Harlow <<a href="mailto:harlowja@yahoo-inc.com" target="_blank">harlowja@yahoo-inc.com</a><br></div><div><div class="h5">
<mailto:<a href="mailto:harlowja@yahoo-inc.com" target="_blank">harlowja@yahoo-inc.com</a><u></u>>> wrote:<br>
<br>
Ok, I think I'm fine with that (although not really sure what that<br>
entails).<br>
<br>
What does the living under the 'oslo program' change?<br>
<br>
Does that entail getting sucked into the incubator (which seems to<br>
be what<br>
your graduating link is about).<br>
<br>
I don't think its a good idea for taskflow to be in the 'incubator'.<br>
Taskflow is meant to be just like any other 3rd party library.<br>
<br>
<br>
No, as we discussed in Hong Kong, there's no reason to add taskflow to<br>
the incubator.<br>
<br>
Whether or not it needs to be part of the oslo program (or any other<br>
program) is a separate question. I'm not opposed to bringing it in, but<br>
didn't see the point when it came up at the summit.<br>
<br>
I understand that moving taskflow into oslo would avoid the policy<br>
decision we have in place to not do symmetric gating on unreleased<br>
versions of things not "owned" by the OpenStack project. However, I<br>
don't know if we want to be testing against the git head of libraries no<br>
matter where they live. As fungi pointed out on IRC, gating against<br>
pre-release versions of libraries may allow us to reach a state where<br>
the software works when installed from git, but not from the released<br>
packages.<br>
<br>
It seems safer to gate changes to libraries against the apps' trunk (to<br>
avoid making backwards-incompatible changes), and then gate changes to<br>
the apps against the released libraries (to ensure they work with<br>
something available to be packaged by the distros). There are lots and<br>
lots of version numbers available to us, so I see no problem with<br>
releasing new versions of libraries frequently.<br>
<br>
Am I missing something that makes that not work?<br>
</div></div></blockquote>
<br>
Requirements wedging.<br>
<br>
Because of entry points any library that specifies any dependencies that OpenStack components specify, at incompatible levels, means that library effectively puts a hold on the rest of OpenStack and prevents it from being able to move forward.<br>
</blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">I have considered changing stevedore so it uses entry points to find plugins, but then handles the import itself specifically to eliminate the requirements checks for plugin dependencies enforced by pkg_resources. So far I haven't convinced myself that it's a good idea, but I'm open to discussion. :-)</div>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Which means every time we need to then change a library dependency it's going to require triggering a release, solely to change library dependencies.<br>
<br>
This is the giant disaster that we created global requirements to avoid, so that we have one nob to turn.<br>
<br>
The only other option is that libraries we own (stackforge / oslo), for condition to be included in global- requirements, *can never* specify a maximum version of any dependency (and I really mean never), and can never specify a minimum greater than current global requirements.</blockquote>
<div><br></div><div><div class="gmail_default" style="font-size:small">That seems like a more appealing solution than testing against unreleased versions via git checkouts. It is is also an approach we could encourage authors of libraries we don't own to use.</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="HOEnZb"><div class="h5"><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>
______________________________<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>