Having imagined things that far, one might tune this further, to
simply assume that every patch is for buildbot only at first, and
to have lists of successfully built/tested patches per platform:
actually, it seems that darcs does have a feature I didn't know
about that might make this fairly straightforward:
$ darcs pull --help
Usage: darcs pull [OPTION]... [REPOSITORY]...
Copy and apply patches from another repository to this one.
--intersection take intersection of all repositories
--union take union of all repositories
[DEFAULT]
If that works the way it sounds, every builder could have its own
repo, say buildbot_X for platform X, and the workflow would
become:
0. for each platform X, have a repo of successfully tested patches,
called buildbot_X
1. push patches as now, to main_repo
2. humans on platform X only pull tested patches, using:
darcs pull -a --intersection buildbot_X main_repo
3. builders pull all patches from main_repo into a temporary repo,
try to build
4. whenever builder X succeeds, it pushes from its temporary repo
to the buildbot_X repo
That is a lot of repos, but as long as main_repo builds, the other
repos are redundant - they only serve to keep the lists of successfully
tested patches in a form that darcs allready understands. In particular,
humans only push to main_repo, and if any buildbot_X repo goes
away, we're simply back to the situation we've got now.
This is somewhat simplistic, as the builders would not try to pull
selectively. So any failing patches would have to be removed or
fixed, or they'd block any other patches being tested successfully
on that platform. But it might be a useful first step?
Claus
PS. looking at http://darcs.haskell.org/buildbot/head/waterfall ,
about a third of the builders seem to be for OSX.
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
