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

[J. T. Farmer]

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
jfarmer at goldsword.com   865-691-6498             Knoxville TN
    Consulting, Design, & Development of Networks & Software