From owner-cvs-all Sun Dec 5 4: 3:42 1999 Delivered-To: cvs-all@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id C42E914C3E; Sun, 5 Dec 1999 04:03:36 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.8.7/8.8.7) with ESMTP id EAA12929; Sun, 5 Dec 1999 04:02:07 -0800 Date: Sun, 5 Dec 1999 04:02:06 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Nick Hibma Cc: Mike Smith , "Matthew N. Dodd" , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern subr_bus.c In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk > > What about the nightly builds of world and the output of that? It should > not be too difficult to drop that into a message and send the tail of > that off to committers when the build fails at some stage. This is what I have going at NASA/Ames right now for a NetBSD spinoff. > > Add a do { } while(1) around it and include LINT (and an alpha cross > build when that is possible) in the build of the kernel and you uncover > most breakages as soon as possible. > > As a side effecy you are left with the most recent SNAP build of that > day. > This is a positive thing and probably should be done. Hell, that's what I do myself with my nightly builds. There are two slightly theoretical problems with this, though: 1. The time lapse between integration and breakage detection is large. Delays that these then induce in other developers become a quadratic delay to quality levels meeting release criteria. 2. It's a personal responsibility thing. If you toss your changes in, and wait for an overnight build to find breakage, chance are good that #1 kicks in and somebody else fixes the breakage that *you* caused. This is not fair and right. In general FreeBSD has been the best at avoiding these problems and has a fantastic record for keeping things clean, so perhaps I'm misdirecting this. In practice, over the last year, I've seen only a few times when things become really unworkable. But what *does* happen is that the lesser known architecture suffers (alpha) and stays broken for a few weeks at a time. If you factor in sparc, which *will* happen sooner or later, you now have three separate architectures, all of which will start to become broken at any given point in time. I'd like to see FreeBSD developer's awareness anticipate this, not lag it by a year or two, where the usual dance of "Oh, that's not as important a platform", or "Well, 4.2 will be the *real* Alpha architecture release, and we're planning on a 4.7 for sparc now!", or "Hmm. We have this set of features in Intel FreeBSD 4.2, but not in FreeBSD Sparc 4.7, and, hmm, something *completely* different in Alpha FreeBSD 4.6", will all happen. Please- I'm already wincing... Why do you think NetBSD releases so *infrequently* and RedHat has completely punted on release feature identity? It's a hard problem, but everyone's awareness about will help. Sorry- I'm tired- it's 0400 in PST8PDT... I'm outta here... -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message