Greg Barniskis wrote:
Karl Denninger wrote:
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.
See my similar comment that echoes Karl's. Now go back and read what
Karl said. He's not tracking -STABLE on a production box, he updated to
-STABLE to fix an existing problem. What bit him in the ass is a problem
with code that "in theory" had not changed and _was_supposed_ to have
been tested. That is, it was working, he upgraded, as everyone tells
you to
do, to get fixes to -RELEASE bugs, not to track -STABLE.
John
------------------------------------------------------------------
John T. Farmer Owner & CTO GoldSword Systems
[EMAIL PROTECTED] 865-691-6498 Knoxville TN
Consulting, Design, & Development of Networks & Software
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
