Date: Wed, 04 Sep 1996 10:34:36 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Terry Lambert <terry@lambert.org> Cc: rkw@dataplex.net, current@FreeBSD.org Subject: Re: Latest Current build failure Message-ID: <3859.841858476@time.cdrom.com> In-Reply-To: Your message of "Wed, 04 Sep 1996 09:34:54 PDT." <199609041634.JAA06605@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 I was talking about a choke point for the developers, not the users. Multiple make worlds running simultaneously don't work out very well, last I checked, and it'd have to be something more like the public bus system model than the private auto model we have now (you climb in and drive whenever you like). Like I said before, I think centralizing it would be a mistake and the real answer to simply fix the build process so that it's less sensitive to anything outside its own build area. > 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. Right. > 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 Why not? There are two ways in which you can easily generate a bogus check build - bad source syncronization and external data pollution. Fixing the tree doesn't avoid bad source sync, that's true, but it does go a long way towards dealing with the second vulnerability. I believe source sync is also manageable through reasonable use of CVSup and CTM, though we still have yet to settle on the "trust" scheme used to tell people when it's safe to go in the water. Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3859.841858476>