Feature proposal: Extended Life Cycle Support

[Bill Nottingham]

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.

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

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.

Bill