From owner-freebsd-current  Fri Jun  7 18:01:18 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id SAA11912
          for current-outgoing; Fri, 7 Jun 1996 18:01:18 -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 SAA11887;
          Fri, 7 Jun 1996 18:01:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with SMTP id RAA17512; Fri, 7 Jun 1996 17:59:42 -0700 (PDT)
To: Terry Lambert <terry@lambert.org>
cc: nate@sri.MT.net (Nate Williams), hackers@freebsd.org,
        freebsd-stable@freebsd.org, FreeBSD-current@freebsd.org
Subject: Re: The -stable problem: my view 
In-reply-to: Your message of "Fri, 07 Jun 1996 14:59:14 PDT."
             <199606072159.OAA04189@phaeton.artisoft.com> 
Date: Fri, 07 Jun 1996 17:59:42 -0700
Message-ID: <17510.834195582@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

[ Jordan, not looking where he's going, stupidly blunders into this
  conversation.  He won't appreciate the magnitude of his mistake until
  later.. ]

OK, wait a sec..

Let me play reductionist for a moment and see if some less complex
scheme that doesn't start with "first, we construct some sub-molecular
assemblers" can be devised (Terry goes "Awwwww!  That'd be no fun
then!").

The question here seems to be "how can we give the users a tree which
always builds", right?  Well, that's certainly not a new question.
Even crazed expatriate brits like Julian Stacey have been calling for
that sort of scheme for years! :-)

I think the _last_ time we went around this merry-go-round, during
which time many of the exact same ideas were floated and rejected as
highly impractical, we decided that the best way of doing it would be
through some selectively cvs-updated trees which were both available
for further supping and used to generate CTM deltas.  When to update
the tree would be gated by the collection of "tokens" from one or more
(preferably more) "token generators".  Each time a cooperating
machined finished a make world, it would send off a token of some sort
(could be an email message) to the server saying, in essence "make
world [completed successfully/failed] from tree [blah] on date [blah]"

My guess is that you'd run these guys once a night, the token receiver
waiting 24 hours for all the reports to filter in and then counting
them up, finally generating a go/no go decision on cvs updating
the tree.

Get somebody to implement the framework, call for volunteer systems to
be "token generators", install the server on freefall and have it use
the scheme to keep the -current and -stable trees up to date.  Anyone
wanting more granular updates can always sup/ctm the CVS tree, right?

						Jordan