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-requ...@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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
