Open Stack

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 <doug at doughellmann.com>
> wrote:
> 
> > [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
> >
> >
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>