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. > 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: openstack-dev-requ...@lists.openstack.org?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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
