From owner-freebsd-stable@FreeBSD.ORG Tue Sep 12 15:55:58 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 802B416A415 for ; Tue, 12 Sep 2006 15:55:58 +0000 (UTC) (envelope-from nalists@scls.lib.wi.us) Received: from mail.scls.lib.wi.us (mail.scls.lib.wi.us [198.150.40.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8760C43D8B for ; Tue, 12 Sep 2006 15:55:49 +0000 (GMT) (envelope-from nalists@scls.lib.wi.us) Received: from [10.1.99.103] ([10.1.99.103]) by mail.scls.lib.wi.us (8.13.1/8.13.1) with ESMTP id k8CFsUo0014130 for ; Tue, 12 Sep 2006 10:54:30 -0500 (CDT) (envelope-from nalists@scls.lib.wi.us) Message-ID: <4506D884.4050605@scls.lib.wi.us> Date: Tue, 12 Sep 2006 10:55:48 -0500 From: Greg Barniskis User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20060909173813.GA1388@FS.denninger.net> <45065C67.6040503@cs.tu-berlin.de> <20060912141547.GA11713@FS.denninger.net> In-Reply-To: <20060912141547.GA11713@FS.denninger.net> 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 15:55:58 -0000 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) , (608) 266-6348