From owner-freebsd-stable@FreeBSD.ORG Tue Sep 12 18:46:26 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6280616A407 for ; Tue, 12 Sep 2006 18:46:26 +0000 (UTC) (envelope-from jfarmer@goldsword.com) Received: from imf20aec.mail.bellsouth.net (imf20aec.mail.bellsouth.net [205.152.59.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC99343D78 for ; Tue, 12 Sep 2006 18:46:22 +0000 (GMT) (envelope-from jfarmer@goldsword.com) Received: from ibm64aec.bellsouth.net ([65.13.105.239]) by imf20aec.mail.bellsouth.net with ESMTP id <20060912184622.YWXK16843.imf20aec.mail.bellsouth.net@ibm64aec.bellsouth.net> for ; Tue, 12 Sep 2006 14:46:22 -0400 Received: from [192.168.1.33] (really [65.13.105.239]) by ibm64aec.bellsouth.net with ESMTP id <20060912184621.EZLW18973.ibm64aec.bellsouth.net@[192.168.1.33]> for ; Tue, 12 Sep 2006 14:46:21 -0400 Message-ID: <4507008D.4070901@goldsword.com> Date: Tue, 12 Sep 2006 14:46:37 -0400 From: "J. T. Farmer" User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 CC: freebsd-stable@freebsd.org References: <20060909173813.GA1388@FS.denninger.net> <45065C67.6040503@cs.tu-berlin.de> <20060912141547.GA11713@FS.denninger.net> <4506D884.4050605@scls.lib.wi.us> In-Reply-To: <4506D884.4050605@scls.lib.wi.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2006 18:46:26 -0000 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@goldsword.com 865-691-6498 Knoxville TN Consulting, Design, & Development of Networks & Software