On Thu, 2003-11-06 at 21:00, Alex Hudson wrote: > On Thu, 2003-11-06 at 20:45, Mr. Adam ALLEN wrote: > I don't think that's actually true. Fedora will rev at much the same > rate as the previous edition of Red Hat, and they do say they will > provide timely updates. It's actually easier to apply a patch than > provide a complete update - your example of backporting is slightly > bogus; most projects offer a stable/development dual track approach, and > provide patches for the stable branch themselves. It's quite rare that a > security fix requires a backport - I don't expect Fedora to package > non-release code. > I wasn't suggesting that unstable code would be shipped... Apache in Shrike is still at 2.0.40 with patches backported from newer versions of Apache. In Fedora there is a possibility that if there is a patch required that the new version will be shipped. The practice with RH was certainly to backport patches. There is less emphasis on keeping a stable environment as previously was the case- so if RH 9 had been Fedora it may already be at 2.0.45 or later via updates. > > For anyone not scared of testing updated first, and not scared to go off > > and recompile if RH's updates break everything then Fedora isn't really > > a real problem. > > That's probably not quite a fair reflection of the situation. > If RH had thrown 2.0.47 out instead of backporting fixes then there would be some breakage in some web-based applications. So if fedora ships initially with Apache 2.0.40 and 2.0.47 breaks users applications- it's the users problem to test updates in a non-production environment first- and recompile the original SRPM with patches if the new update does break things. With RedHat Linux it was more a case of trusting that RedHat updates wouldn't break too many things afterwards- with Fedora this promised -- Regards, Adam Allen. adam [at] dynamicinteraction.co.uk pgp http://search.keyserver.net:11371/pks/lookup?op=vindex&search=adam%40dynamicinteraction.co.uk
Attachment:
signature.asc
Description: This is a digitally signed message part