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.
pgpjTuwEKm3Of.pgp
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
