Doug, Let me poll folks on the oslo meeting today and reply back.
Thanks, dims On Mon, Aug 24, 2015 at 8:56 AM, Doug Hellmann <[email protected]> wrote: > Excerpts from Davanum Srinivas (dims)'s message of 2015-08-24 07:50:17 > -0400: > > Doug, > > > > Since we have not announced a freeze, we should give folks at least > another > > week. I'd defer to you and lifeless about date for stable branch creation > > and version capping etc. If we could give a bit more time for the new > oslo > > libraries coming out this cycle, that would be great as well. > > We did set the freeze date early in the cycle, didn't we? > > We've frozen the week before the rest of the projects for the past > 2-3 cycles, since that gives us time to focus on bugs before the > release candidates are cut, without having to freeze for the entire > month between the application feature freeze and the releases. > > Are there features in process now that are going to land in time for an > application to use them and get *that* landed by the overall freeze for > L3 next week? > > Doug > > > > > Thanks, > > dims > > > > > > > > On Mon, Aug 24, 2015 at 6:58 AM, Doug Hellmann <[email protected]> > > wrote: > > > > > [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 > > > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
