Date: Wed, 4 Sep 1996 09:34:54 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: terry@lambert.org, rkw@dataplex.net, current@FreeBSD.org Subject: Re: Latest Current build failure Message-ID: <199609041634.JAA06605@phaeton.artisoft.com> In-Reply-To: <10860.841793798@time.cdrom.com> from "Jordan K. Hubbard" at Sep 3, 96 04:36:38 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > There are writer locks which you are not permitted to release until > > a full build succeeds. But of course, that's shot down each time it > > is brought up. > > Because it's essentially meaningless. A full build succeeds *where*, > Terry? On the engineer's personal box? I can't count the number of > build errors I've seen corrected with a sheepish "sorry guys, it > worked on *my* box!" follow-up commit. A full build succeeds on a checked out source tree with a limited path relatively pointed into the build area, of course. In effect, this would mean that there was no difference in the engineers build environment and that of anyone who checked out the code at any lock release time stamp. This assumes that the writer lock is held over the build process; if it were a nightly build run by cron on another box, then it would work as well as the engineer's personal box. Of course, we used the full feature set of CVS between time synced NFS mounted boxes, so any hodge-podge environment less than that would not perform quite as well. However, the problem is one of not putting up crap for general download, and it can be solved by only putting a newer version up after a successful build, rather than establishing an integrated developement environment. There are many paths to the same results. The benefit here is that the person doing the checkin will not get his bits on his next tree synchronization until his bit work. Kind of a dual incentive. > Since engineers will always > mess with their own boxes and the source tree still has far too many > external dependencies to consider this a reasonable risk (down, > Richard! :-), the distributed model can't work yet. Actually, "Go, Richard!... Richard! - Richard! - Richard!". > That leaves one with the idea of doing it on a "build server" which > is kept ideologically and morally pure, an increasingly hypothetical > machine we're talking about here since it'd have to be fast enough to > not become a choke-point and administered well enough that developers > had various mechanisms available for "signing up" for the next build > if one was already in progress. Not freefall, that's for sure. Adding latency is not the same thing as adding a "choke-point"; the only increasingly hypothetical thing here is the idea that a broken source tree is less of a barrier to progress than an increased latency for change availability. And you're right, Freefall would be a bad choice for the build machine... it has too much additional software installed such that new dependencies would not be immediately obvious. Look at the "shared lib Motif XEmacs" port problem that sneaked through: a result of too much installed software on the ports machine. Or if we believe Richard (and I happen to believe him), a result of failed segregation of host/build environments. > Anyway, the real answer is to fix the source tree and everyone here > knows it. If one could build /usr/src completely "stand-alone" > starting with a small reference-set of bootstrap binaries, and where > these should come from or how they should be generated is a matter on > which I'd welcome some debate, then a developer *could* check in > changes after a certain degree of local testing and be far more > assured that they'll work for everyone else. This will help in the external dependencies case, but it won't help in the "agregate changes fail to compile" case -- which seems to be the most frequent problem area. I think the most frequent problem area remains unaddressed, even in a fixed source tree. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609041634.JAA06605>