Open Stack

On 11/9/2015 12:21 AM, Tony Breeds wrote:
> On Fri, Nov 06, 2015 at 06:42:05PM +0000, Jeremy Stanley wrote:
>> On 2015-11-06 10:12:21 -0800 (-0800), Clint Byrum wrote:
>> [...]
>>> Note that it's not just backporters though. It's infra resources too.
>>
>> Aye, there's the rub. We don't just EOL these branches for fun or
>> because we hate old things or because ooh shiny squirrel. We EOL
>> them at a cadence where the community has demonstrated it loses its
>> ability to keep them healthy and testable (evaluated based on
>> performance over recent prior cycles because we have to warn
>> downstreams well in advance as to when they should expect upstream
>> support to cease).
>
> Sure and Juno is in bad shape, as Matt will attest but I think it can be fixed
> ;P
>
>> Downstream maintainers regularly claim they will step up their
>> assistance upstream to keep stable branches alive if only we'll
>> extend the lifespan on them, so we tried that with Icehouse and,
>> based on our experience there, scaled back the lifespan of Juno
>> again accordingly. Keep in mind that extending support of stable
>> branches necessarily implies supporting a larger _number_ of stable
>> branches in parallel. If we switched from 12 months after release to
>> 18 then we're maintaining at least 3 stable branches at any point in
>> time. If we extend it to 24 months then that's 4 stable branches.
>
> Yes I agree and frankly I'm disappointed that the support I received in Tokyo
> hasn't arrived on this thread (yet).  As to the number of stable branches,
> I'm nervous about this.  I don't really want an additional period of
> life-support for Juno to mandate a similar commitment for Kilo.
>
> I realise it's a slippery slope.
>
>> To those who suggest solving this by claiming one is a LTS release
>> every couple years, you're implying a vastly different upgrade model
>> than we have now. If we declare Juno is a LTS and leave it supported
>> another 12 months, then 6 months from now when we EOL stable/kilo
>> we'll be telling deployers that they have to upgrade from supported
>> stable/juno through unsupported stable/kilo to supported
>> stable/icehouse before running stable/mitaka. Or else you're saying
>> you intend to fix the current inability of our projects to skip
>> intermediate releases entirely during upgrades (a great idea, and so
>> I'm thrilled by those of you who intend to make it a reality, we can
>> revisit the LTS discussion once you finish that).
>
> I carefully *didn't* suggest and OpenStack LTS :)
>
> Yours Tony.
>
>
>
> __________________________________________________________________________
> 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
>

Given the requirements whack-a-mole in stable/juno, and to an extent in 
stable/kilo, I just don't think it's really worth keeping alive what we 
have for stable/juno right now.

I think once we end of life Kilo we'll have a much better idea of how 
stable/liberty is going with upper-constraints. If we're not constantly 
putting out gate wedge issues due to capped requirements, that makes for 
a happier stable maint / QA / dev team that is then more willing to keep 
things around longer because they just work (unit test jobs, grenade 
jobs and tempest/dsvm jobs).

Keeping the branches around longer if they are working isn't so bad - 
you only consume CI resources as needed when changes on stable are 
proposed and updated, which is like the experimental queue on master. 
There is the nightly periodic jobs but that's just once a day.

As already noted, the other hit is branchless Tempest running stable 
compat jobs, which is a problem for anyone trying to get Tempest changes 
to land. Think of the race bugs you have to recheck against just for 
master, then multiply that times however many stable branches you have 
to maintain and that's what a Tempest change has to pass through. We 
could also branch Tempest at a certain point though. Tempest has tags 
that correspond to release milestones for the core projects. Internally 
we create branches for Tempest to align with the branches that are EOL 
upstream so we can fix requirements issues as needed (like capping 
requirements on grizzly or havana, for example).

-- 

Thanks,

Matt Riedemann