Open Stack

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

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



-- 
Davanum Srinivas :: https://twitter.com/dims