Feature proposal: Extended Life Cycle Support
Jeroen van Meeuwen
kanarip at kanarip.com
Mon Jul 6 18:41:48 UTC 2009
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
More information about the fedora-devel-list
mailing list