Open Stack

Excerpts from Davanum Srinivas (dims)'s message of 2017-05-08 06:12:51 -0400:
> On Mon, May 8, 2017 at 3:52 AM, Bogdan Dobrelya <bdobreli at redhat.com> wrote:
> > On 06.05.2017 23:06, Doug Hellmann wrote:
> >> Excerpts from Thierry Carrez's message of 2017-05-04 16:14:07 +0200:
> >>> Chris Dent wrote:
> >>>> On Wed, 3 May 2017, Drew Fisher wrote:
> >>>>> "Most large customers move slowly and thus are running older versions,
> >>>>> which are EOL upstream sometimes before they even deploy them."
> >>>>
> >>>> Can someone with more of the history give more detail on where the
> >>>> expectation arose that upstream ought to be responsible things like
> >>>> long term support? I had always understood that such features were
> >>>> part of the way in which the corporately avaialable products added
> >>>> value?
> >>>
> >>> We started with no stable branches, we were just producing releases and
> >>> ensuring that updates vaguely worked from N-1 to N. There were a lot of
> >>> distributions, and they all maintained their own stable branches,
> >>> handling backport of critical fixes. That is a pretty classic upstream /
> >>> downstream model.
> >>>
> >>> Some of us (including me) spotted the obvious duplication of effort
> >>> there, and encouraged distributions to share that stable branch
> >>> maintenance work rather than duplicate it. Here the stable branches were
> >>> born, mostly through a collaboration between Red Hat developers and
> >>> Canonical developers. All was well. Nobody was saying LTS back then
> >>> because OpenStack was barely usable so nobody wanted to stay on any
> >>> given version for too long.
> >>>
> >>> Maintaining stable branches has a cost. Keeping the infrastructure that
> >>> ensures that stable branches are actually working is a complex endeavor
> >>> that requires people to constantly pay attention. As time passed, we saw
> >>> the involvement of distro packagers become more limited. We therefore
> >>> limited the number of stable branches (and the length of time we
> >>> maintained them) to match the staffing of that team. Fast-forward to
> >>> today: the stable team is mostly one person, who is now out of his job
> >>> and seeking employment.
> >>>
> >>> In parallel, OpenStack became more stable, so the demand for longer-term
> >>> maintenance is stronger. People still expect "upstream" to provide it,
> >>> not realizing upstream is made of people employed by various
> >>> organizations, and that apparently their interest in funding work in
> >>> that area is pretty dead.
> >>>
> >>> I agree that our current stable branch model is inappropriate:
> >>> maintaining stable branches for one year only is a bit useless. But I
> >>> only see two outcomes:
> >>>
> >>> 1/ The OpenStack community still thinks there is a lot of value in doing
> >>> this work upstream, in which case organizations should invest resources
> >>> in making that happen (starting with giving the Stable branch
> >>> maintenance PTL a job), and then, yes, we should definitely consider
> >>> things like LTS or longer periods of support for stable branches, to
> >>> match the evolving usage of OpenStack.
> >>>
> >>> 2/ The OpenStack community thinks this is better handled downstream, and
> >>> we should just get rid of them completely. This is a valid approach, and
> >>> a lot of other open source communities just do that.
> >>
> >> Dropping stable branches completely would mean no upstream bugfix
> >> or security releases at all. I don't think we want that.
> >>
> >
> > I'd like to bring this up once again:
> >
> > option #3: Do not support or nurse gates for stable branches upstream.
> > Instead, only create and close them and attach 3rd party gating, if
> > asked by contributors willing to support LTS and nurse their gates.
> > Note, closing a branch should be an exceptional case, if only no one
> > willing to support and gate it for a long.
> 
> As i mentioned before, folks can join the Stable Team and make things
> like this happen. Won't happen by an email to the mailing list.
> 
> Thanks,
> Dims

Right. We need to change the tone of this thread from "you should do X"
to "I want to do X, where should I start?"

Doug