From owner-freebsd-stable@FreeBSD.ORG Fri May 5 19:52:15 2006 Return-Path: X-Original-To: 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 65DD616A426; Fri, 5 May 2006 19:52:15 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id A939643D45; Fri, 5 May 2006 19:52:14 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 0468546C76; Fri, 5 May 2006 15:52:13 -0400 (EDT) Date: Fri, 5 May 2006 20:52:12 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Paul Allen In-Reply-To: <20060505185424.GD31769@regurgitate.ugcs.caltech.edu> Message-ID: <20060505204248.W46997@fledge.watson.org> References: <35c231bf0605031821s582b6d03j3ee9d434a596f62a@mail.gmail.com> <20060504021908.GA714@soaustin.net> <35c231bf0605032011s65fbb1aby742438465ee98ee7@mail.gmail.com> <20060504033300.GA39935@xor.obsecurity.org> <44598615.3040400@rogers.com> <20060504044758.GA41047@xor.obsecurity.org> <44599732.1050905@rogers.com> <20060505080543.GD5466@garage.freebsd.pl> <35c231bf0605051049t2761281ar97b9634b8279b1fd@mail.gmail.com> <445B991F.3050600@rogers.com> <20060505185424.GD31769@regurgitate.ugcs.caltech.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: stable@freebsd.org, Pawel Jakub Dawidek , Mike Jakubik , David Kirchner , Kris Kennaway , Mark Linimon Subject: Re: quota deadlock on 6.1-RC1 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: Fri, 05 May 2006 19:52:16 -0000 On Fri, 5 May 2006, Paul Allen wrote: > One detail of this has to do with version numbering. The FreeBSD version > number says a lot more about the userland than it does about the kernel per > se. > > If we were to version the kernel arch, I think it would look more like this: > > '94 1.1.5.1 (Last Net/2) Version 0 > Nov '94 2.0.5 (First unencumbered release) > Aug '96 2.1.5 > Nov '96 2.2 Version 1 > Oct '98 3.0 Major VM changes... Version 2 > Mar '00 4.0 refinement of 3.x > Jan '03 5.0 Major SMP changes Version 3 > Jul '05 6.0 refinement of 5.x > ??? 7.0 refinement of 5.x,6.x One of the "problems" we've had in the last ten years was the piling on of features during the 5.x release cycle. Because two very large development projects were going on simultaneously (KSE, SMPng), at the same time as the dotcom bubble burst, greatly reducing various companies commitments of staff resources to FreeBSD, the brach for 5-STABLE kept getting deferred. For better, or sometimes worse, new features kept getting added to avoid stalling all development while SMPng and KSE stabilized. These new features kept deferring the branch date, of course :-). I think there is universal recognition that while the features in FreeBSD 5.x were really great, trickling them in over a longer period of time, and avoiding the steep stability surves for them happening simultaneously, would have been better (in retrospect). The reason we're now trying to move onto a fixed schedule release cycle is to try and limit that: instead of saying "Yes, we can defer the release for new feature ", we instead say, "We can't add feature because there isn't time for it to stabilize before the release". By being a little less feature agressive in the short term, we can increase stability, and in fact improve feature delivery in the long term. So there are a variety of new features in the pipeline for 7.x, but we've actually been focussing almost exclusively on stability and performance so far. So what to expect in the future? A slightly less agressive feature schedule for major releases -- 5.x had UFS2, KSE, SMPng, TrustedBSD, OpenPAM, a new gcc, etc. 6.x had significant network stack refinements, VFS SMPng work, etc, but nothing like the feature list of 5.x. The main distinguishing factor for 7.x right now is Audit, which while a good bullet feature, but relatively non-intrusive. I'd expect to see further UFS and VFS work, etc, possibly including a move to UFS journalling from the bgfsck model, a Giant-free NFS client, further refinement of locking in the storage stack, ARM support, and so on. But by driving feature integration by schedule, things should go more smoothly. For example, Audit is in 7.x -- we wanted to merge it for 6.1, but decided that the 6.1 schedule simply didn't allow it, so it will likely appear in 6.2 and 7.0. That's a lot better than merging it prematurely, deferring the release 6 months for it to stabilize, and shipping it prematurely anyway. Robert N M Watson