On Mon, May 8, 2017 at 3:52 AM, Bogdan Dobrelya <[email protected]> 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 >> Doug >> >>> >>> The current reality in terms of invested resources points to (2). I >>> personally would prefer (1), because that lets us address security >>> issues more efficiently and avoids duplicating effort downstream. But >>> unfortunately I don't control where development resources are posted. >>> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > -- > Best regards, > Bogdan Dobrelya, > Irc #bogdando > > __________________________________________________________________________ > 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
