From owner-freebsd-stable Sun May 21 10: 9:21 2000 Delivered-To: freebsd-stable@freebsd.org Received: from ns1.sunesi.net (ns1.sunesi.net [196.15.192.194]) by hub.freebsd.org (Postfix) with ESMTP id 4374B37B547; Sun, 21 May 2000 10:09:07 -0700 (PDT) (envelope-from nbm@sunesi.net) Received: from nbm by ns1.sunesi.net with local (Exim 3.03 #1) id 12tZDM-0007vH-00; Sun, 21 May 2000 19:08:32 +0200 Date: Sun, 21 May 2000 19:08:32 +0200 From: Neil Blakey-Milner To: Darren Reed Cc: Jonathan Lemon , freebsd-stable@freebsd.org, ps@freebsd.org, Cy.Schubert@uumail.gov.bc.ca Subject: Re: 4.0_STABLE Broken (was Re: FTP proxy without translation no longer working? (fwd)) Message-ID: <20000521190831.A30246@mithrandr.moria.org> References: <20000521102808.C5468@prism.flugsvamp.com> <200005211626.CAA12901@avalon.reed.wattle.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200005211626.CAA12901@avalon.reed.wattle.id.au>; from darrenr@reed.wattle.id.au on Mon, May 22, 2000 at 02:26:50AM +1000 Organization: Sunesi Clinical Systems X-Operating-System: FreeBSD 3.3-RELEASE i386 X-URL: http://rucus.ru.ac.za/~nbm/ Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon 2000-05-22 (02:26), Darren Reed wrote: > Okay. So you want to play "pass the buck". Backing out that change > (which does not fix *any* bugs!) will "fix the problem". As it is, > you've introduced a _new feature_ to the _STABLE branch and broken > something. In my book, that's two crosses you've marked up: changes > to _STABLE must not break it and new features must be extensively > tested in -current before committing to a release branch. I agree. We have to test the change in -CURRENT before committing it to -STABLE, and thus it is probably the best move to try back it out, since it should be early enough for there not be too many conflicts. It's not at all obvious whether the move to -STABLE was in error - it may just be an indication of the lack of ipfilter users who happened to check out -CURRENT in the time it was in use. revision 1.131 date: 2000/03/27 19:14:21; author: jlemon; state: Exp; lines: +15 -4 Add support for offloading IP/TCP/UDP checksums to NIC hardware which revision 1.130.2.1 date: 2000/05/05 13:36:51; author: jlemon; state: Exp; lines: +15 -4 MFC: delayed checksum work. This also brings the mbuf size up to 256. It's taken 16 days to find the problem in -STABLE, and 55 days since it was added in -CURRENT for the problem to be seen. 40 days of no problems is generally considered sufficient. > Do you need any more ? I am given to understand that FreeBSD > doesn't have a very strict (read absent) release engineering > policy which allows for this sort of thing to happen. There haven't been much in the way of complaints. Creating a major stumbling block in the way of changes may cause more problems. Of course, if it becomes obvious that there is an out-of-hand problem, it should be re-evaluated. A suggestion may be for you, and others, to create regression tests for your subsystems that should be checked in the case of commits to your general area. If you don't place reminders that your code may be affected, it's going to be forgotten. It certainly didn't show up in the 40 days of the checksumming code in -CURRENT. > Jordan, if you're reading this, you should give some *serious* > thought to setting up a proper release engineering team - they > should be dealing with this, not me and Jonathan directly pissing > on each other. Allowing the "unwashed" (i.e. committers) to commit > to released and stable branches is an invitation for disaster, IMHO. I doubt a "release engineering team" will be any better at finding problems in code that received no complaints in the 40 or so days it was in -CURRENT. A release engineering team will require regression tests, though. Neil -- Neil Blakey-Milner Sunesi Clinical Systems nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message