Simon Marlow wrote:
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.
Similar rate limiting as you proposed for (1) could be applied; ie, no
more than one such repo per week.
I don't quite understand why (2) is much easier to implement and having
a tag a week in the main tree marking a buildable state seems quite
attractive to me. Anyway, Option (2) is fine, too.
However, just http://darcs.haskell.org/ghc-2007-02-09 isn't good enough.
We need a consistent set of ghc repo and core packages. At least, in
my experience, it's not uncommon having build problems due to ghc/ and
libraries/base/ being out of sync, and at least when the build system
changes, many build problems are in conjunction with packages.
Manuel
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
