Manuel M T Chakravarty wrote:
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.
For (2) I was thinking we could just add a target in the top-level Makefile that
runs 'darcs push' for each of the repos, and invoke that as a step from
buildbot. It's a bit simpler than having to invent a tag name, tag each repo
and push the tags.
If instead we had a new repo for each snapshot as per Simon PJ's suggestion, I
would do it like this: after the initial darcs-all pull, tar up the whole tree.
If the build succeeds, scp the tarball to darcs.haskell.org and unpack it in
the right place. The snapshot repos would be partial, but that's hopefully not
a problem. Again this can all be a target in the top-level Makefile invoked via
BuildBot. (my builds have passwordless SSH access already because I upload the
binary/source distributions to haskell.org).
Andy's staging repo idea is interesting, but I think it's more work than the
above two strategies, so we should see if the easy way is sufficient first.
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.
Yes - I was assuming that we'd snapshot the core packages too (but not the extra
packages).
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
