Re: plans for long term support releases?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Horst H. von Brand wrote:
Thomas M Steenholdt <tmus@xxxxxxx> wrote:

[...]

In my mind, something like this could be accomplished in several
ways. If backporting is too much work (I know it takes time) then
perhaps it could be done by following upstream releases like we do
today, but for a longer time.

One of the reasons /not/ to ugrade and wanting to stick with the same
distribution release is precisely because new upstream releases break
stuff...

Yes, GCC 4 is a /much/ better C++ compiler than 3 [OK, OK, the language 4
accepts contains something that at least resembles C++, that cannot be said
of 3], but many things that compiled and worked fine with 3 just won't
build on 4 without /much/ work.

Yes, Python 2.6 is nicer than 2.5, but many packages break (remember? ;-)

Yes, PHP 5 is safer than 4, but websites built with 4 won't work OOB.

And a long etc. So the way out is backporting patches, or better backfixing
(== finding out how to trigger the bug, figure out if it (or something
similar) is present in the old version, fixing the bug, checking that this
really fixes the problem and doesn't create new ones). Tedious, hard
work. Sure, you'll find people eager to do it (mostly terminal masochists),
you might be able to find people able to do it right (but they probably are
much more excited by the idea of hacking on the latest&greatest). You won't
find anybody willing to test the result (at least not enough to make a
difference). So...

If it is /that/ important to somebody, they'll be willing to shell out for
a long-term maintained distribution like RHEL (or band together and do the
work). If not, they aren't really interested, more than an "it would be
real nice if I did not have to upgrade Fedora each year or so"


I'm aware of the work involved in maintaining packages, backporting fixes etc. And I agree completely that in the current setup, the fixes will probably not be tested properly. Also, it does not seem like something like this is desired for Fedora (at this point at least), and that's an acceptable answer to my inquiry too.

I only suggested that we thought about it, which a lot of people did. There are several reasons why we should NOT do it, so there's not much sense in leaving the "case" open.

Perhaps at a later point, it'll make sense to reevaluate. Now's just not the time.


Perhaps the solution is to re-launch legacy in a more integrated
way?!? I heard the cut back, but I don't know how much.

AFAIU, it dried on the wine.

/Thomas

--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux