Suggestion re altering the build system

[Simon Marlow]

Simon Peyton-Jones wrote:
> |   1. We tag all the repos after a successful bootstrap on each platform.
> |      Main problem with this: profusion of tags, obscuring 'darcs changes'
> |      and 'darcs query tags'.  Space itself isn't really an issue; a tag
> |      only adds a few hundred bytes.
> |
> |      We could mitigate the effect by rate-limiting the tags, say only tag if
> |      there hasn't been a tag in the last week.  Then we'd get one
> |      guaranteed-buildable state per week or so, which seems reasonable.
> |
> |   2. We keep a separate set of repos that are only updated after a successful
> |      build.  Perhaps one set of repos per platform.
> |      Main problem with this: ensuring atomicity during the update (probably
> |      not likely to be a significant problem in practice).
> |      Second problem: this doesn't store the repo state of every successful
> |      build, only the most recent one.
> |
> | Personally I lean towards (2), as it's much easier to implement.  Any further
> | comments?
> 
> (2) seems good to me.  Furthermore, if we published
>         Last good build is at repo http://darcs.haskell.org/ghc-2007-02-09
> (so the date is in the repo name), and refrain from publishing until the repo is really there, there'd be no atomicity issues would there?
> 
> (We can just delete older ones after a bit.)

Indeed, that's a good idea, although it's more work than just pushing.  We 
wouldn't want to create a complete new set of repos for every successful build, 
I don't think.

Cheers,
	Simon