Open Stack

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151109/d9594c51/attachment.pgp>