From owner-freebsd-current  Wed Sep  4 10:35:38 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id KAA22581
          for current-outgoing; Wed, 4 Sep 1996 10:35:38 -0700 (PDT)
Received: from time.cdrom.com (time.cdrom.com [204.216.27.226])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA22576
          for <current@FreeBSD.org>; Wed, 4 Sep 1996 10:35:36 -0700 (PDT)
Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id KAA03862; Wed, 4 Sep 1996 10:34:36 -0700 (PDT)
To: Terry Lambert <terry@lambert.org>
cc: rkw@dataplex.net, current@FreeBSD.org
Subject: Re: Latest Current build failure 
In-reply-to: Your message of "Wed, 04 Sep 1996 09:34:54 PDT."
             <199609041634.JAA06605@phaeton.artisoft.com> 
Date: Wed, 04 Sep 1996 10:34:36 -0700
Message-ID: <3859.841858476@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-current@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

> 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