[Openstack-operators] LTS Dreaming ... [was] Help: Liberty installation guide (English).

Yih Leong, Sun. yihleong at gmail.com
Wed Apr 12 15:49:47 UTC 2017


The previous discussion for LTS [1] was proposed by vendors as well as a
few large operators who willing to assign developers for the work (not sure
if the case might change?)

One key concern (as per last discussion) is the Infra CI constraints for
LTS.
If there are more interest in this topic, we can re-introduce the
discussion [1] again.



On Wed, Apr 12, 2017 at 7:46 AM, Shamail Tahir <itzshamail at gmail.com> wrote:

>
>
> On Wed, Apr 12, 2017 at 10:10 AM, Jonathan D. Proulx <jon at csail.mit.edu>
> wrote:
>
>> On Tue, Apr 11, 2017 at 06:01:00PM -0500, Matt Riedemann wrote:
>>
>> :Right, but the distros aren't interested in funding developers for LTS
>> :upstream work, much less a lot of the stable branch support upstream. It
>> :shouldn't be surprising why, that's where they can make money.
>>
>> No doubt that's their thought.  I for one don't think that would make
>> any difference in who's paying them while it would cut down on their
>> costs, but as you say:
>>
>> :As has been mentioned already, none of this is news and we go over it at
>> :least once per year.
>>
>> So I doubt anyone's shifting their corporate priorities around this.
>>
>
> FWIW, we had a discussion and user story[1] on this topic in the Product
> WG last year... the distro vendors were not against upstreaming things to
> enable a longer upstream support but the topic divided into three main
> areas:
> 1) What would be the impact to infra requirements (this discussion
> happened when node count was in reduction)?
> 2) Who would be responsible for taking and acting on patch requests for
> older releases?
> 3) Should the overall release cadence be longer than 6 months (we had
> representation from both sides that were comfortable with upgrades and
> rolling in changes that wanted more frequent releases to get fixes and
> features faster and organizations that wanted releases to be more "stable"
> so they weren't either upgrading or planning for an upgrade almost
> continuously)
>
> The user story didn't move forward since we couldn't find an optimal
> solution for #3 and #1 and #2 were also left open. Sharing this for context.
>
> [1] https://review.openstack.org/#/c/276933/9/user-stories/
> proposed/stable_branch_support.rst
>
>
>>
>> :Oh btw, Mitaka EOL was scheduled for yesterday.
>>
>> Yay! I'm EOL again!
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
>
> --
> Thanks,
> Shamail Tahir
> t: @ShamailXD
> tz: Eastern Time
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170412/40a48647/attachment.html>


More information about the OpenStack-operators mailing list