[ 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