On Mon, 6 Jul 2009 13:56:43 -0400, Bill Nottingham <notting@xxxxxxxxxx> wrote: > Kevin Fenzi (kevin@xxxxxxxxx) 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
