ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!

[Greg Barniskis]

Karl Denninger wrote:

> You've never been able to get reliability by jumping from release to release,

eh? Been doing that for 10 years without a single significant 
problem. Granted, we've been lucky enough here not to encounter (a) 
flakier hardware components and/or (b) flakier combos of drivers & 
apps & configs & heavy loads (a.k.a. bugs in FreeBSD) that other 
folks admittedly have encountered in the most painful ways.

Releases aren't guaranteed to be perfect, nothing is, but plenty of 
users have no complaints at all about release point reliability. 
They're just not posting their non-problems to the lists.

> and every time someone comes in the lists to complain about something being
> broken in -RELEASE, the advice is to go to and track -STABLE!

Maybe splitting hairs, but advising a user with a problem to try 
using the -STABLE code that exists at the time of the problem report 
is really not the same as advising them to /track/ STABLE.

If you /track/ STABLE by frequently cvsupping it and rebuilding your 
system, you will very likely encounter a serious problem sooner or 
later. That's why tracking it is not recommended for production 
systems.

On the other hand if you update a production system to a point in 
time of STABLE that fixes a particular bug that plagued a release 
point, and then you don't update again until the next release point 
or security advisory, you will very likely find joy.

-- 
Greg Barniskis, Computer Systems Integrator
South Central Library System (SCLS)
Library Interchange Network (LINK)
<gregb at scls.lib.wi.us>, (608) 266-6348