building head fails in main/GHC.hs:2223:50
claus.reinke at talk21.com
Thu May 3 12:29:33 EDT 2007
>> would it be possible to set some maximum failure time (1 week or so),
>> so that buildbot failures for longer than that would cause all new patches
>> to be put on hold until the head+libs _build_ again on all major platforms?
> FWIW, that wouldn't have helped the build system fixes get done any
> quicker, and the other problems tend to be short-lived.
yes, but these seem to be fairly active times, with lots of contributions,
overhauls, bug fixes, clean-ups, feature evolutions, etc coming in (which
is great, i think!-). that means that all these short-lived problems accumulate
and overlap each other, so that every time one pulls necessary fixes for
one end, one also pulls interesting patches that disturb another end. that
still settles down after a while, but it has -not for the first time- frustrated
me for about a week between stable points.
you're right, putting all that wonderful creativity on hold during fixing
times or delaying progress via complex automated-build-before-apply
systems might not be the answer, but the problem is all too real.
how about this, then: darcs allows for selective pulls, so is there a way
of tagging patches as belonging to different categories? submitters
could tag their patches according to simple priorities, using reserved
words in patch subjects:
- FIX_BUILD: essential fixes to restore one of the builds
- FIX_BUG: essential fixes to bugs in successfully built systems
- no tag: implies the usual run-of-the-mill patch we have now
the second and third categories are the reasons we are addicted to
building ghc head in the first place, but if building doesn't work, we
could switch to 'darcs pull -ap "FIX_BUILD"', pulling only those
patches that help to stabilize the situation. once the build we're
interested in works again, we can start pulling the remaining patches,
if we need them as well, starting with bug fixes, leaving all the rest
to stable times.
> Incidentally, the HEAD has mostly been buildable; it's only if you put
> extra, unbuildable libraries in the tree that it's not been working, for
> which there is a simple workaround!
well, yes, though buildbot has looked rather red even for fast builds.
but of course, we want those extra libs, and skipping those for which
we have not yet installed the pre-requisites shouldn't be a show-stopper;-)
More information about the Cvs-ghc