From owner-cvs-all Sun Dec 5 11:13:17 1999 Delivered-To: cvs-all@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id 65D261540E; Sun, 5 Dec 1999 11:13:11 -0800 (PST) (envelope-from hibma@skylink.it) Received: from skylink.it (va-160.skylink.it [194.185.55.160]) by ns.skylink.it (8.9.1/8.8.8) with ESMTP id UAA10341; Sun, 5 Dec 1999 20:13:06 +0100 Received: from localhost (localhost [127.0.0.1]) by skylink.it (8.9.3/8.9.3) with ESMTP id UAA00973; Sun, 5 Dec 1999 20:08:49 +0100 (CET) (envelope-from hibma@skylink.it) Date: Sun, 5 Dec 1999 20:08:49 +0100 (CET) From: Nick Hibma X-Sender: n_hibma@henny.jrc.it Reply-To: Nick Hibma To: Matthew Jacob 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 > > 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. You mean, the fact that the test builds fail until the problem has been fixed, makes the detection of other breakages slower? I don't think that world will often be broken in more than one place at the same time, or at least it hasn't happened recently. > 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. Breaking the build and being pointed out as the one that broke it, up to now has made people cautious. That is probably going to be stronger rather than weaker with a more direct feedback loop. > 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. Very true, and that attitude within committers should be changed, to make sure alpha builds become reliable, very true. Nick -- hibma@skylink.it n_hibma@freebsd.org USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message