Simon Peyton-Jones wrote:
| 4. Trying to maintain a branch is still frustrating. I've just spend 4
| hours (and had to rebuild ghc 6 or 7 times) trying to sync ghc-ndp with
| head. Even worse, in the last couple of months, we would have problems
| with building head itself more often than not. I think we lost *weeks*
| trying to work around this. IMO, this is a problem with the current
| development process. From my gcc hacking days I remember that the gcc
| maintainers would only accept patches if they passed the testsuite on at
| least two architectures. This worked wonders for the stability of
| gcc-head. I'd like to propose a similar policy for ghc, at least for
| patches which change OS-specific stuff (it's probably sufficient to test
| changes to the typechecker, simplifier etc. on just one architecture).
| Alternatively, could at least vastly destabilising changes (which the
| dynamic linking stuff is bound to be) be done in a branch? Concurrent
| development doesn't really work otherwise.
Our current plan (were you in the loop when we discussed this?) is to have a
snapshot darcs repo, that is the last known clean build. (Question: do we need
one per architecture?)
If you had that, you'd be happy, right? You could just pull from that. You
wouldn't get the latest patches -- but you can't *both* have the latest patches
*and* a known good build.
Ian, how's the last-good-build mechanism coming along?
It is set up to happen for the Windows build, but for some reason it didn't work
yet, and the builds have failed for various other reasons in the meantime. I'll
investigate today.
I am dedicating today to stabilising the builds. Hopefully we'll see some
improvement tomorrow.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
