<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>I'd be up for that 'dual' gating. It would help make sure that nothing major is breaking in the next version as well as the version released on pypi isn't also causing problems.</div>
<div><br>
</div>
<div>Although git head gating does seem odd, especially as git head/trunk is where things change (and should be allowed to break and change, change is good) and the level of false positives that would be raised might become to much of a pain. I'd rather not
discourage innovation on trunk if we can; since this is what stable releases are for.</div>
<div><br>
</div>
<div>Btw the sqlalchemy changes (unpinning) should be fine. </div>
<div><br>
</div>
<div>Ivan did a couple of tests (basic stuff, not full integration).</div>
<div><br>
</div>
<div>- https://review.openstack.org/#/c/64869/</div>
<div>- https://review.openstack.org/#/c/64881/</div>
<div><br>
</div>
<div>Both passed basic unit tests (full integration against real mysql, not sqlite will happen soon I hope with <a href="https://bugs.launchpad.net/taskflow/+bug/1265886">https://bugs.launchpad.net/taskflow/+bug/1265886</a>).</div>
<div><br>
</div>
<div>If we really need to I can push out a 0.1.2 with the unpinned version (one of the above reviews).</div>
<div><br>
</div>
<div>-Josh</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Doug Hellmann <<a href="mailto:doug.hellmann@dreamhost.com">doug.hellmann@dreamhost.com</a>><br>
<span style="font-weight:bold">Date: </span>Friday, January 3, 2014 at 11:44 AM<br>
<span style="font-weight:bold">To: </span>Joshua Harlow <<a href="mailto:harlowja@yahoo-inc.com">harlowja@yahoo-inc.com</a>><br>
<span style="font-weight:bold">Cc: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>, Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] [requirements] - taskflow preventing sqla 0.8 upgrade<br>
</div>
<div><br>
</div>
<div>
<div>
<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 12:45 PM, Joshua Harlow <span dir="ltr">
<<a href="mailto:harlowja@yahoo-inc.com" target="_blank">harlowja@yahoo-inc.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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 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>
</blockquote>
<div><br>
</div>
<div>
<div class="gmail_default" style="font-size:small">No, as we discussed in Hong Kong, there's no reason to add taskflow to the incubator. </div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">Whether or not it needs to be part of the oslo program (or any other program) is a separate question. I'm not opposed to bringing it in, but didn't see the point when it came up at the summit.</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">I understand that moving taskflow into oslo would avoid the policy decision we have in place to not do symmetric gating on unreleased versions of things not "owned" by the OpenStack project. However, I don't
know if we want to be testing against the git head of libraries no matter where they live. As fungi pointed out on IRC, gating against pre-release versions of libraries may allow us to reach a state where the software works when installed from git, but not
from the released packages.</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">It seems safer to gate changes to libraries against the apps' trunk (to avoid making backwards-incompatible changes), and then gate changes to the apps against the released libraries (to ensure they work with
something available to be packaged by the distros). There are lots and lots of version numbers available to us, so I see no problem with releasing new versions of libraries frequently.</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">Am I missing something that makes that not work?</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">
<br>
Or were u mainly referring to the 'devstack-gate integration' section?<br>
<br>
I'd be interested in hearing dougs opinion here (cc'd him) as<br>
<a href="https://etherpad.openstack.org/p/icehouse-oslo-splitting-the-incubator" target="_blank">https://etherpad.openstack.org/p/icehouse-oslo-splitting-the-incubator</a><br>
would seem to cause even more of these types of new 3rd party libraries to<br>
appear on pypi (and therefore causing similar issues of transitive<br>
dependencies as taskflow).<br>
<br>
Will bug u on #openstack-infra soon :-)<br>
<div class="HOEnZb">
<div class="h5"><br>
On 1/3/14, 9:05 AM, "Sean Dague" <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<br>
<br>
>On 01/03/2014 11:37 AM, Joshua Harlow wrote:<br>
>> So taskflow was tested with the version of sqlalchemy that was available<br>
>> and in the requirements at the time of its 0.1 release (taskflow syncs<br>
>> it's requirements from the same global requirements). From what I<br>
>> remember this is the same requirement that everyone else is bound to:<br>
>><br>
>> SQLAlchemy>=0.7.8,<=0.7.99<br>
>><br>
>> I can unpin it if this is desired (the openstack requirements repo has<br>
>> the same version restriction). What would be recommended here? As more<br>
>> code moves to pypi reusable libraries (oslo.db when it arrives comes to<br>
>> mind) I think this will be hit more often. Let's come up with a good<br>
>> strategy to follow.<br>
>><br>
>> Thoughts??<br>
><br>
>So I think that given taskflow's usage, it really needs to live under<br>
>the Oslo program, and follow the same rules that are applied to oslo<br>
>libraries. (<a href="https://wiki.openstack.org/wiki/Oslo#Graduation" target="_blank">https://wiki.openstack.org/wiki/Oslo#Graduation</a>)<br>
><br>
>Which means it needs to be part of the integrated gate, so we can update<br>
>it's requirements globally. It also means that changes to it will be<br>
>gated on full devstack runs.<br>
><br>
>We can work through the details on #openstack-infra. ttx has been doing<br>
>the same for oslo.rootwrap this week.<br>
><br>
> -Sean<br>
><br>
>--<br>
>Sean Dague<br>
>Samsung Research America<br>
><a href="mailto:sean@dague.net">sean@dague.net</a> / <a href="mailto:sean.dague@samsung.com">
sean.dague@samsung.com</a><br>
><a href="http://dague.net" target="_blank">http://dague.net</a><br>
><br>
>_______________________________________________<br>
>OpenStack-dev mailing list<br>
><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</span>
</body>
</html>