From owner-freebsd-stable@FreeBSD.ORG Thu May 4 01:42:43 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 3048716A405; Thu, 4 May 2006 01:42:43 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id D08E143D45; Thu, 4 May 2006 01:42:42 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id B28CB1A3C29; Wed, 3 May 2006 18:42:42 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 28D6151A2C; Wed, 3 May 2006 21:42:42 -0400 (EDT) Date: Wed, 3 May 2006 21:42:42 -0400 From: Kris Kennaway To: David Kirchner Message-ID: <20060504014241.GA38346@xor.obsecurity.org> References: <20060502171853.GG753@dimma.mow.oilspace.com> <20060502172225.GA90840@xor.obsecurity.org> <20060502174429.GH753@dimma.mow.oilspace.com> <44579EE1.6010300@rogers.com> <20060502180557.GA91762@xor.obsecurity.org> <4457A02C.9040408@rogers.com> <20060502182302.GA92027@xor.obsecurity.org> <20060503110503.O58458@fledge.watson.org> <35c231bf0605031821s582b6d03j3ee9d434a596f62a@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline In-Reply-To: <35c231bf0605031821s582b6d03j3ee9d434a596f62a@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Cc: stable@freebsd.org, Robert Watson 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: Thu, 04 May 2006 01:42:43 -0000 --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 03, 2006 at 06:21:39PM -0700, David Kirchner wrote: > On 5/3/06, Robert Watson wrote: > >This means that > >they will take a significant amount of time to fix, and that each fix is= =20 > >high > >risk, as it is likely to reveal latent bugs. This means that each fix w= ill > >require a lot of testing -- months of testing, in fact. So the choice is > >really, do we release 6.1, or do we skip it and do a 6.2 in a few months= . =20 > >As > >the release engineer, Scott has concluded that releasing now offers a gr= eat > >benefit to many people, although the bugs present may penalize some. Mind > >you, in some cases the bugs also exist in 6.0, so they don't represent > >regressions, so much as bugs that continue to persist. >=20 > However, one could argue that as quotas worked OK in releases prior to > 6.0 (and perhaps earlier), that there is a longer-term regression. There was a quota regression in 6.0. It was fixed 2 months ago. AFAIK snapshots and quotas are also broken in 5.x, so the remaining problem is not a regression. The reasons it cannot be fixed in 6.1 have already been discussed. > I don't understand the need to issue a new release according to a > strict schedule if it means leaving critical bugs that affect a > fundamental feature of the OS: the filesystem itself. I agree that you don't understand: the 6.1 release cycle has been going on for over 3 months now, and the original ship date was passed months ago. This is not a "strict schedule" by any reasonable definition of the term, and the release engineers have been extremely flexible in slipping the dates to accomodate the many bugs that have been fixed during the release cycle. > This assumes that 6.1 absolutely must be released -- must it, in its > current state? The VFS code is indeed incredibly complicated, but it > is also absolutely critical. The server is completely useless if > filesystem operations fail. Would there really be harm in putting off > a release until these well-acknowledged bugs are taken care of? Yes, it ties up a lot of developer resources and causes the release engineers to burn out. As several key developers have already explained, if you adopt a policy of delaying the release until all serious bugs are fixed, there will be no more releases of FreeBSD ever again. I assume you don't want that, which means that you have to draw a line somewhere. The line has now been drawn. Kris --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEWVwRWry0BWjoQKURAiWrAJ9ttzHN9v/19DQ5xIy8/mBDhJLqrwCg8EUB ipQQbfbWGJsA4uqeJi9gFF0= =CuKy -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs--