long term support release

Les Mikesell lesmikesell at gmail.com
Mon Jan 28 18:13:42 UTC 2008


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


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.

-- 
   Les Mikesell
    lesmikesell at gmail.com




More information about the devel mailing list