Date: Sun, 5 Dec 1999 04:02:06 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: Nick Hibma <hibma@skylink.it> Cc: Mike Smith <msmith@FreeBSD.org>, "Matthew N. Dodd" <winter@jurai.net>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern subr_bus.c Message-ID: <Pine.BSF.4.10.9912050348200.28621-100000@beppo.feral.com> In-Reply-To: <Pine.BSF.4.20.9912051039190.297-100000@henny.jrc.it>
next in thread | previous in thread | raw e-mail | index | archive | help
>
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9912050348200.28621-100000>