Open Stack

On 01/03/2014 02:44 PM, Doug Hellmann wrote:
>
>
>
> On Fri, Jan 3, 2014 at 12:45 PM, Joshua Harlow <harlowja at yahoo-inc.com
> <mailto:harlowja at yahoo-inc.com>> wrote:
>
>     Ok, I think I'm fine with that (although not really sure what that
>     entails).
>
>     What does the living under the 'oslo program' change?
>
>     Does that entail getting sucked into the incubator (which seems to
>     be what
>     your graduating link is about).
>
>     I don't think its a good idea for taskflow to be in the 'incubator'.
>     Taskflow is meant to be just like any other 3rd party library.
>
>
> No, as we discussed in Hong Kong, there's no reason to add taskflow to
> the incubator.
>
> 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.
>
> 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.
>
> 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.
>
> Am I missing something that makes that not work?

Requirements wedging.

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.

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.

This is the giant disaster that we created global requirements to avoid, 
so that we have one nob to turn.

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.

	-Sean

-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net