Les Mikesell <lesmikesell@xxxxxxxxx> wrote: > Ralf Corsepius wrote: > > > ?!? You do not agree that fixing bugs in libraries and applications > > people tripped over when running application A in situation X, often > > bugs people trip over when running other applications in other > > situations? This has happened 1000s of times and will happen 1000s > > of times again. Sure. But what if fixing said bug creates other bugs? And if the affected applications/uses are far in between? What if the manpower to do the analysing, fixing, testing is scarce? > > Actually, I would consider such cases to be the norm. > >>>> In my experience, they end getting fixed by moving forward. > >>> A bug is only fixed if it takes place in the current release. > >> Strange definition of bug fix. > > What's strange about this? In real-life manufacturers will be sued for > > "not fixing bugs in a current release" - Avoiding such situations is > > called "customer care". > > Customer: "Garage, when I turn on my car's head lights, the heating > > starts running at full power." > > Garage : "We reported it upstream to the car's manufacturer. You might > > try the next model available at your local dealer next year. Until > > then, open the windows." Can be a quite reasonable position, depending on exactly how serious the bug is. And remember that you are getting Fedora for free, no guarantees attached. > Fedora has a unique situation in this respect though. By policy RHEL > will not add new features in updates and since the upstream app > developer generally only cares about going forward, that means someone > has to do the work of backporting bugfixes minus features into > something that sort-of resembles the originally shipped app > version. Fedora, however is perfectly free to fix the fedora version > by shipping an update to the current app version, accepting the > upstream fix in it fully-featured form. > While I'd like to see the final update of a fedora rev. slipstream > itself into exactly the packages in RHEL/Centos (at least in the > versions where that would make sense) so no extra work would be > required to continue running safely with security/bugfix updates for > several more years, it could be left up to the packager to decide if > he wants to ship more advanced versions (and commit to maintaining > them separately). For example, I don't think it made much sense other > than following policy to maintain dovecot in it's pre-1.0 version as > shipped in RHEL4 after upstream did a 1.x release. OK, let's recapitulate what I've seen on this thread Objectives for an LTS: ---------------------- - Keep base (kernel, libraries, DE, ...) the same, but please give me bleeding edge <each has their own selected list of applications> - Keep userland the same, but give support to newest hardware as soon as it comes out - Run Fedora for a longer period, so one doesn't get caught in the upgrade mill. Usually cited "for some years", but I get the impression on average it would be for a few months - Backport "only bug fixes" [Note that someone's "nasty new feature" could very well be the real fix for someone else's "bug"...] How to do it: ------------- - Just get some people at RH/some volunteers do it, it can't be /that/ hard [Yea, right] - Just freeze the Fedora from which RHEL is branched, and so use the updates for RHEL Why isn't CentOS + CentOS-Plus + EPEL enough: --------------------------------------------- [No, I haven't seen any real argument here] -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
