Feature proposal: Extended Life Cycle Support

[Jeroen van Meeuwen]

On Mon, 6 Jul 2009 13:56:43 -0400, Bill Nottingham <notting at redhat.com>
wrote:
> Kevin Fenzi (kevin at scrye.com) said: 
>> - The issue I have with this plan (and the others very like it) is that
>>   if you say "we will just do updates for the things we have people
>>   willing to do updates" it means the entire end of life distro is not
>>   covered and the likelyhood of an outstanding security issue is quite
>>   high. There is a chicken and egg issue here where unless there is
>>   enough coverage we shouldn't do it, but we can't find out if there is
>>   enough coverage without doing it. Doing it in such a way that it
>>   fails just gives everyone a bad name and feeling, IMHO.
>> 
>> - An indeterminate time is also bad IMHO. How can these corporations
>>   plan if they don't know how much time you are adding here?
> 
> These two are my big concerns - doing this badly is worse than not
> doing it, IMO. When it comes to user's security, I don't want to give
> promises we can't keep, or leave them in a bind.
> 

This has been addressed in another response to the quoted message from
Kevin.

> Other notes:
> 
> - while F9 updates may be 3+ hours, F11 updates is currently *14-15*
hours,
>   and there aren't as many updates now as there will be; that number
>   will only go up. (Yay deltarpms!)

The support of deltarpms within the extended life cycle is something that
can be (re-)considered.

> - You don't provide API/ABI guarantees. Which means you're signing up
>   for more work than you might want if you're pushing updates to
>   Firefox/xulrunner. (And if you're not providing updates for that for
>   the desktop, it's not worth starting.)

Thanks for the heads-up.

> - You state that "the only reason that makes upgrading the distribution a
>   requirement is the continuous availability of security updates. "
> 
> This implies that you're fine with the feature set of an older
distribution
> after a while; but you don't want something like RHEL or CentOS. Is it
> just the 'RHEL is sort of old in the tooth right now' sort of philosophy?
> Because by your metrics, a RHEL released now (or in 3 months, or
whatever)
> would be fine. 
> 

The "or whatever" is sorta funny...

(1) The opt-in upgrade every 3 years or every 6 months is a *major*
difference.
(2) The required upgrade every 7 years or every year is a *major*
difference.


At point 1 where RHEL is released, it might be fine. At point 2 where
Fedora N+1 is released RHEL gets old. You have another 4 (!) Fedora
releases (do I hear anyone say ~20 features each?) coming your way to make
you appreciate the more rapid release cycle; if only you didn't hate the
rapid required upgrade cycle as much...

Now, if one could opt-in to upgrade every 6 months for a longer period of
time, say 19 months instead of 13 months (leaving 7 or 1 month(s)
respectively to upgrade to N+1 or N+2, as said before), then I foresee
greater adoption and thus potentially greater participation.

> Also, just going back to original first principles:
> 
> 	http://fedoraproject.org/wiki/Objectives
> 
> "Fedora is not interested in having a slow rate of change, but rather to
be
> innovative. We do not offer a long-term release cycle because it diverts
> attention away from innovation."
> 
> Long term support, in general, goes against the directly objectives of
the
> project. If it's felt that extending the life cycle a *specific,
> measureable
> amount* would be of more benefit to the project, that's probably a board
> issue,
> not a FESCo issue.
> 

I've heard before it does not feel like a Feature. I guess it'll be up to
FESCo to decide on whether or not to make a decision on this, or to relay
the issue to the Board?

-- Jeroen