Date: Sun, 5 Dec 1999 20:08:49 +0100 (CET) From: Nick Hibma <hibma@skylink.it> To: Matthew Jacob <mjacob@feral.com> 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.20.9912052003340.492-100000@henny.jrc.it> In-Reply-To: <Pine.BSF.4.10.9912050348200.28621-100000@beppo.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.20.9912052003340.492-100000>