Date: Sun, 21 May 2000 19:08:32 +0200 From: Neil Blakey-Milner <nbm@mithrandr.moria.org> To: Darren Reed <darrenr@reed.wattle.id.au> Cc: Jonathan Lemon <jlemon@flugsvamp.com>, 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> 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 %2B1000 References: <20000521102808.C5468@prism.flugsvamp.com> <200005211626.CAA12901@avalon.reed.wattle.id.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000521190831.A30246>