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 <bdobr...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev