Open Stack

Excerpts from Michael Johnson's message of 2018-06-12 08:41:57 -0700:
> I think we should continue with option 1.
> 
> It is an indicator that a project is active in OpenStack and is
> explicit about which code should be used together.
> 
> Both of those statements hold no technical water, but address the
> "human" factor of "What is OpenStack?", "What do I need to deploy?",
> "What is an active project and what is not?", and "How do we advertise
> what OpenStack can provide?".

I don't expect for oslo.i18n to see any patches during Stein, but it is
still maintained. Is it still part of OpenStack under this definition?

> 
> I think 2 and 3 will just lead to confusion and frustration for folks.
> 
> Michael
> On Mon, Jun 11, 2018 at 7:50 AM Doug Hellmann <doug at doughellmann.com> wrote:
> >
> > Excerpts from Thierry Carrez's message of 2018-06-11 11:53:52 +0200:
> > > Hi everyone,
> > >
> > > As some of the OpenStack deliverables get more mature, we need to adjust
> > > our release policies to best handle the case of deliverables that do not
> > > need to be updated that much. This discussion started with how to handle
> > > those "stable" libraries, but is actually also relevant for "stable"
> > > services.
> > >
> > > Our current models include cycle-tied models (with-intermediary,
> > > with-milestones, trailing) and a purely cycle-independent model. Main
> > > OpenStack deliverables (the service components that you can deploy to
> > > build an OpenStack cloud) are all "released" on a cycle. Libraries are
> > > typically maintained per-cycle as well. What happens if no change is
> > > pushed to a service or library during a full cycle ? What should we do
> > > then ?
> > >
> > > Options include:
> > >
> > > 1/ Force artificial releases, even if there are no changes
> > >
> > > This is the current state. It allows to reuse the exact same process,
> > > but creates useless churn and version number confusion.
> > >
> > > 2/ Do not force releases, but still create branches from latest releases
> > >
> > > In this variant we would not force an artificial re-release, but we
> > > would still create a branch from the last available release, in order to
> > > be able to land future patches and do bugfix or security releases as needed.
> > >
> > > 2bis/ Like 2, but only create the branch when needed
> > >
> > > Same as the previous one, except that rather than proactively create the
> > > stable branch around release time, we'd wait until the branch is
> > > actually needed to create it.
> > >
> > > 3/ Do not force releases, and reuse stable branches from cycle to cycle
> > >
> > > In this model, if there is no change in a library in Rocky, stable/rocky
> > > would never be created, and stable/queens would be used instead. Only
> > > one branch would get maintained for the 2 cycles. While this reduces the
> > > churn, it's a bit complex to wrap your head around the consequences, and
> > > measure how confusing this could be in practice...
> > >
> > > 4/ Stop worrying about stable branches at all for those "stable" things
> > >
> > > The idea here would be to stop doing stable branches for those things
> > > that do not release that much anymore. This could be done by switching
> > > them to the "independent" release model, or to a newly-created model.
> > > While good for "finished" deliverables, this option could create issues
> > > for things that are inactive for a couple cycles and then pick up
> > > activity again -- switching back to being cycle-tied would likely be
> > > confusing.
> > >
> > >
> > > My current preference is option 2.
> > >
> > > It's a good trade-off which reduces churn while keeping a compatibility
> > > with the system used for more active components. Compared to 2bis, it's
> > > a bit more work (although done in one patch during the release process),
> > > but creating the branches in advance means they are ready to be used
> > > when someone wants to backport something there, likely reducing process
> > > pain.
> > >
> > > One caveat with this model is that we need to be careful with version
> > > numbers. Imagine a library that did a 1.18.0 release for queens (which
> > > stable/queens is created from). Nothing happens in Rocky, so we create
> > > stable/rocky from the same 1.18.0 release. Same in Stein, so we create
> > > stable/stein from the same 1.18.0 release. During the Telluride[1] cycle
> > > some patches land and we want to release that. In order to leave room
> > > for rocky and stein point releases, we need to skip 1.18.1 and 1.19.0,
> > > and go directly to 1.20.0. I think we can build release checks to ensure
> > > that, but that's something to keep in mind.
> > >
> > > Thoughts ?
> > >
> > > [1] It's never too early to campaign for your favorite T name
> >
> > Although I originally considered it separate, reviewing your summary
> > I suspect option 2bis is most likely to turn into option 3, in
> > practice.
> >
> > I think having the choice between options 2 and switching to an
> > independent release model (maybe only for libraries) is going to
> > be best, at least to start out.
> >
> > Stein will be the first series where we have to actually deal with
> > this, so we can see how it goes and discuss alternatives if we run
> > into issues.
> >
> > Doug
> >
> > __________________________________________________________________________
> > 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
>