From owner-freebsd-stable@FreeBSD.ORG Sat Jun 21 00:45:28 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 3FB9B37B401 for ; Sat, 21 Jun 2003 00:45:28 -0700 (PDT) Received: from out001.verizon.net (out001pub.verizon.net [206.46.170.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FB5743FA3 for ; Sat, 21 Jun 2003 00:45:27 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com ([141.149.47.46]) by out001.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030621074526.IFDO12592.out001.verizon.net@mac.com> for ; Sat, 21 Jun 2003 02:45:26 -0500 Message-ID: <3EF40D15.6050400@mac.com> Date: Sat, 21 Jun 2003 03:45:25 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030612 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3EF36B9F.6090405@mail.flyingcroc.net> <20030620180948.F76384@sasami.jurai.net> <3EF38AFB.5040500@mail.flyingcroc.net> <20030620185830.M76384@sasami.jurai.net> In-Reply-To: <20030620185830.M76384@sasami.jurai.net> X-Enigmail-Version: 0.76.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out001.verizon.net from [141.149.47.46] at Sat, 21 Jun 2003 02:45:26 -0500 cc: stable@FreeBSD.ORG Subject: Re: /etc/libmap.conf MFC? 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: Sat, 21 Jun 2003 07:45:28 -0000 Matthew N. Dodd wrote: [ ... ] > I'm still not sure we should be encouraging new features in -STABLE; > additional hardware support and bugfixes are one thing... Doesn't the term "MFC" refer to a change or new feature that has already been added to -CURRENT, and is under consideration for being backported to -STABLE because the change is important, of general interest and utility, etc? If the question is "when should new features not be merged back into 4.x", my response would be that should happen after 5.x is tagged as -STABLE and 5.x is being actively recommended for to all users including newbies, not just early adopters. If the concern is "is it better to spend time trying to get 5.x -STABLE then it is to spend time on 4.x", well, that makes perfect sense to me. -- -Chuck PS: What does not make much sense is 'releasing' a 'new version' of software which is not intended for the end userbase to actually use. Attempting to reduce the scope of problems with a .0 release is a noble goal, but good intentions can be taken too far. If a user asks "what version should I run" and the answer isn't "the latest release", well, that indicates a problem. If a release candidate isn't expected to be better than the prior numerical version for the end users, then the release candidate isn't ready. Perhaps I'm drifting off-topic a bit, but I remember administering Sun machines during the transition from SunOS 4.1.x to what marketting called Solaris 2.x. Sun didn't do itself or anyone else a favor with SunOS 5.0 through about 5.5; it wasn't until Solaris 2.5.1/SunOS 5.5.1 that Sun's customers got something significantly better than a .0 release, or (perhaps arguably) better than the prior major version. That really sucked, people, so please excuse my vehemence. [ Or don't. If the comparison between SunOS 5.x and FreeBSD 5.x earns me flames, rabid criticism, and the undying emnity of whomever, so be it. :-) ]