Quoting Jesse Keating <jkeating@xxxxxxxxxxxxxxx>:
Sure, for RHL it is about stability. But with FC it was more about extending the lifespan. And to me, it really doesn't make sense to change the way in which the Fedora Project treats a release just because a different set of folks are touching it.
You can though think it does make sense to change the handling because it is EOL, independent of who is touching it. EOL means end of development which means end of upgrades, at least to some. One question is what size of upgrades are you talking about. There's a big difference in going from kernel 2.4.12 to 2.4.13 versus going from 2.4.12 to 2.6.10 (just made up version numbers, but you get the idea). Same with going from apache 1.x.5 to 1.x.6 versus going from apache 1.x.5 to apache 2.x.y. If the upgrade doesn't require other non-trivial upgrades, doesn't require too many other upgrades, doesn't require manual reconfiguration, doesn't break the command line API, doesn't break the system, then I don't have a problem with an upgrade. If the upgrade does any of the above, then I have a problem.
I'm trying to establish a scenario where the Fedora Project as a whole has a certain lifespan for a Fedora (core+extras) release. An end user really shouldn't care how the updates are generated, just that they are published and announced in the same spaces, and that the content of said updates.
As long as they don't break more than they fix...
-- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)
-- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! -- fedora-legacy-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-legacy-list
