Feature proposal: Extended Life Cycle Support

[Josh Boyer]

On Mon, Jul 06, 2009 at 10:27:43AM +0100, David Woodhouse wrote:
>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
>> questions
>> 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.
>
>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
>long.
>
>So if three years is too long and one year is too short, what _do_ you
>want? 2 years? 18 months?
>
>18 months would be a single extra Fedora release, and that _might_ be
>something we could make some progress on.
>
>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? 

No, the sky does not fall.  There are a few hurdles though.

1) Master mirror space.  This used to be an issue, in that we had to move
older releases to alt.fp.o in order to make space for the new release.  I
believe we still do that, so either the yum.repo.d config files for the EOL
release would need to be changed, or we'd have to grow a lot more mirror space.

2) Update push times.  It takes 3+ hours to mash f9-updates right now.  Keeping
that time duration in the official updates pushing for an EOL release would
be really annoying.  Particularly since we are already going to hit some major
time hurdles as F10 and F11 age and definitely when we add F12.

>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.
>
>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.

It doesn't work that way in practice.  If it is allowed, it is official.  You
have to coordinate downtimes, End-of-Life-After-Death times, etc.  The minute
it's disabled early for one reason or another (space, time constraints, etc)
people will cry foul even if it was "unofficial".

>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.

I would encourage people to run this as a secondary architecture.  CVS still
remains open for commits.  You could just have a secondary koji hub for the
builds.

>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?

There is minimal pain, yes.  Mostly to infrastructure and rel-eng.  What I
don't immediately see is the benefit to Fedora overall.

josh