Feature proposal: Extended Life Cycle Support
Jeroen van Meeuwen
kanarip at kanarip.com
Mon Jul 6 15:27:23 UTC 2009
On Mon, 06 Jul 2009 10:27:43 +0100, David Woodhouse <dwmw2 at infradead.org>
> On Sun, 2009-07-05 at 17:52 +0200, Jeroen van Meeuwen wrote:
>> As described on the Feature page, but if there's any specific
>> about the reasoning on there I'll be happy to answer those questions.
> I had read the feature page, in which you claim that a three-year cycle
> "disqualifies the distribution(s) as desktop Linux distributions".
> I didn't see any justification for that assertion, especially given that
> you're simultaneously claiming that a 13-month lifetime isn't long
> _enough_ for you.
Hold on... Realistically, the current 13 month life cycle is about 7-8
months too long for me personally as I upgrade to rawhide anywhere between
Beta and GA everywhere I can ;-) This extended life cycle feature is not to
support my own needs and/or expectations.
The longer (3 year approx.) release cycle doesn't necessarily disqualify a
distribution for desktop environments, but for some environments that have
a desire to run newer software. The shorter life cycle (~13 months) however
is a major downside to many businesses -in my experience.
> You've conveniently dodged the question of what lifetime you _do_ want
> to provide, by saying 'yet to be determined'. But you must have _some_
> idea, if you're so sure that 13 months is too short and 36 months is too
As the page says, at:
my initial thoughts are 6 months extra (~19 months total). This will give
us enough time to establish whether this is successful (although not
meeting it's full potential success after this short a period of time), and
whether this is sustainable.
> How much work would it take, to make it possible for us to still ship
> updates for a release which has officially reached EOL? Does the sky
> fall on our heads if we don't push the 'Kill F-9' button in koji and
> bodhi precisely 1 month after the F-11 release?
Overall, roughly estimated, it'll take 1 FTE to do all the work involved.
Whether that is one person doing all the work (including patching,
building, maintaining infra, pushing, signing, etc, etc..), or 80 people
doing all kinds of various stuff, doesn't matter; It'd still come down to
approximately 1 FTE.
> As a first step, perhaps we try that -- still officially state that the
> release is EOL and should not be used, but _allow_ interested people
> like Jeroen (and the original package owners, _if_ they are so inclined)
> to continue to build and push updates, instead of forcibly cutting off
> builds and updates as we do at the moment.
As suggested on the wiki page, we rename "EOL" to End-Of-Support (EOS),
only to make a given release EOL after the period of time we decide to
provide security updates for. Of course, not renaming EOL to EOS does not
block anything from moving forward.
> That _isn't_ something we would publish as a 'feature' though -- it
> would strictly _unofficial_, although you'd be permitted to use the
> Fedora infrastructure for it.
> If it turns out that there _is_ enough interest and the interested
> people are _actually_ keeping on top of security fixes etc., then maybe
> we could consider officially admitting that it happens, and _then_
> publishing it as a 'feature'. And/or extending it to more than one extra
> release. But those are all questions for the future.
> If it doesn't take too much infrastructure work, I see no reason why we
> shouldn't let them _try_. It doesn't hurt Fedora at all, does it?
Jeroen van Meeuwen
More information about the devel