Open Stack

[Moving this discussion onto the list, so the background isn’t lost.]

> Begin forwarded message:
> 
> From: Robert Collins <robertc at robertcollins.net>
> Subject: Re: oslo freeze this week?
> Date: August 23, 2015 at 6:42:33 PM EDT
> To: Doug Hellmann <doug at doughellmann.com>
> Cc: Thierry Carrez <thierry at openstack.org>, Davanum Srinivas <davanum at gmail.com>
> 
> On 24 August 2015 at 10:21, Doug Hellmann <doug at doughellmann.com> wrote:
>> 
>>> On Aug 23, 2015, at 5:51 PM, Robert Collins <robertc at robertcollins.net> wrote:
>>> 
>>> On 24 August 2015 at 09:28, Doug Hellmann <doug at doughellmann.com> wrote:
>>>> I have marked on my version of the release schedule that we will have the Oslo libraries frozen this week. Are we still planning to do that? We should figure out what that means as far as creating stable branches and version caps and all of those things that caused us so much trouble last cycle.
>>> 
>>> We're not capping anything. We're depending on constraints to carry us
>>> forward. The constraints for tox stuff works but isn't widely
>>> deployed: it is partly waiting on a governance change... I think we
>>> should use this as a forcing function for projects to opt-in to that.
>>> grenade uses constraints so only stable branches should be affected by
>>> that.
>> 
>> I’m not sure what governance change you mean?
> 
> Turns out we should extend the project testing interface as part of
> adding the contraints targets for tox. Nakato is drafting that at the
> moment.
> 
>>>> Do we think we have enough of the constraints stuff going to not cut stable branches, yet, and work using capped requirements? Do we want to try not capping this cycle?
>>> 
>>> stable branches are orthogonal to constraints IMO. If the only reason
>>> for the stable branch is the capped requirements, then I would not
>>> make the branch.
>> 
>> We will (most likely) have stable branches for libraries, at some point, to handle bug fixes. The question is do we want them now or later? One argument for creating them at some point before we actually need them is that fewer people can create branches than can approve patches on them, so if we end up needing a stable release of a library we want to go ahead and have it.
>> 
>> We might be able to go without stable branches for now, and create them closer to the end of the cycle. I think we’ll end up using the same versions we have now, more or less, so I’m not sure it buys us that much to wait.
>> 
>> If want to try to avoid library stable branches, we need to add jobs to test the master versions of libraries against stable versions of applications to avoid regressions. Those are likely to break quickly because of other requirements changes (minimums raising), at which point we have to stop what we’re doing to reconfigure test jobs and create a stable branch before continuing work on the library’s master branch. So I’m inclined, for the sake of “ease of reasoning” to just go ahead and create the stable branches, even if we don’t cap requirements.
> 
> Sure, I have no real opinion on that presently: its something I have
> weakly held and not reasoned-in-details opinions.
> 
>>> 
>>>> We should probably discuss this on the -dev list, but I wanted to spur some thinking. I’ll start a thread after the release team meeting tomorrow.
>>> 
>>> Cool.
>> 
>> So now that I’ve gone and continued the thread, would you object to me forwarding this message to the mailing list to avoid us having to replay it there? We can continue the discussion there if there’s more to say.
> 
> No objections.
> 
> -Rob
> 
> -- 
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud