Fedora products, to upgrade rather than backport?

[Eric Rostetter]

Quoting Jesse Keating <jkeating at j2solutions.net>:

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