[Moving this discussion onto the list, so the background isn’t lost.] > Begin forwarded message: > > From: Robert Collins <[email protected]> > Subject: Re: oslo freeze this week? > Date: August 23, 2015 at 6:42:33 PM EDT > To: Doug Hellmann <[email protected]> > Cc: Thierry Carrez <[email protected]>, Davanum Srinivas > <[email protected]> > > On 24 August 2015 at 10:21, Doug Hellmann <[email protected]> wrote: >> >>> On Aug 23, 2015, at 5:51 PM, Robert Collins <[email protected]> >>> wrote: >>> >>> On 24 August 2015 at 09:28, Doug Hellmann <[email protected]> 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 <[email protected]> > Distinguished Technologist > HP Converged Cloud
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
