long term support release
Horst H. von Brand
vonbrand at inf.utfsm.cl
Mon Jan 28 21:28:05 UTC 2008
Les Mikesell <lesmikesell at gmail.com> 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
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
- 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
- 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
More information about the devel