From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 08:13:30 2003 Return-Path: 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 4B30816A4B3 for ; Mon, 22 Sep 2003 08:13:30 -0700 (PDT) Received: from raven.ravenbrook.com (raven.ravenbrook.com [193.82.131.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 443664400D for ; Mon, 22 Sep 2003 08:13:27 -0700 (PDT) (envelope-from nb@ravenbrook.com) Received: from thrush.ravenbrook.com (thrush.ravenbrook.com [193.112.141.249]) h8MFDJc9054734; Mon, 22 Sep 2003 16:13:19 +0100 (BST) (envelope-from nb@ravenbrook.com) Received: from thrush.ravenbrook.com (localhost [127.0.0.1]) by thrush.ravenbrook.com (8.12.9/8.12.9) with ESMTP id h8MFDLeo013354; Mon, 22 Sep 2003 16:13:21 +0100 (BST) (envelope-from nb@thrush.ravenbrook.com) From: Nick Barnes To: Bill Woods In-Reply-To: Message from Bill Woods Date: Mon, 22 Sep 2003 16:13:21 +0100 Message-ID: <13353.1064243601@thrush.ravenbrook.com> Sender: nb@ravenbrook.com cc: Jacob cc: stable@freebsd.org Subject: Re: upgrading X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2003 15:13:30 -0000 At 2003-09-22 14:27:25+0000, Bill Woods writes: > While I tend to agree with you on the steps you outline, there > should NOT be a firestorm on stable, things should be fairly well > tested BEFORE being commited to stable. Maby its time to revisit the > branch naming scheme, considering the name "stable" carries with it > certian implications. I am generally in agreement, but the only way to flush out some bugs seems to be to MFC the code to -STABLE. The project clearly doesn't have the resources to test every configuration, and few people are prepared to run -CURRENT (I know I'm not). The recent PAE problems are not typical. There's always a spectrum between getting the latest code (new functionality, support for recent hardware, etc) and total stability. FreeBSD provides easy ways to select points on that spectrum: 1. If you want the bleeding edge, run -CURRENT. 2. If you want code which has survived on -CURRENT, has been tested fairly well, appears fine in general use, but might break under high stress or in unusual configurations, run -STABLE. 3. If you want to do a little better than that, run -STABLE and pick your cvsup times with care. 4. If you want code which you can really rely on, run x.y-RELENG. 5. If you want code which doesn't change, run x.y-RELEASE. 6. You can always stick to 2.2.8.... For the record, I've maintained machines at various different points on this spectrum for some years now (I upgraded our last 2.2.x machine to 4.x a while back), and have never experienced significant flakiness (even with -CURRENT). At present, my main externally-visible servers run 4.7-RELENG and 4.8-RELENG, my internal servers run 4.8-RELEASE, and my desktop runs -STABLE. When a new -RELEASE comes out, I try it out before deploying it internally, and usually wait a few weeks after that before pushing it onto the external servers. Nick B