Feature proposal: Extended Life Cycle Support

[Jeroen van Meeuwen]

On Mon, 6 Jul 2009 07:11:30 -0400, Josh Boyer <jwboyer at gmail.com> wrote:
> 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.
> 

These are very valid constraints/concerns which I've added to the Feature
wiki page. This is stuff I like to hear ;-)

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

This (downtimes, etc) is why initially, I wanted the period of time between
EOS and EOL to match a release cycle. I guess these dependencies make it a
little more required to stick with periods of time equal to the
release-cycle of a Fedora release.

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

It that's the solution to problems (to be) set forth, then so be it. I
would love to have it as part of the primary infrastructure but then again
it's no blocker.

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

Is it you question the benefit given in the paragraph on the Feature page,
or ...?

Thanks,

Kind regards,

Jeroen van Meeuwen
-kanarip