long term support release

[Horst H. von Brand]

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