| 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? I'm sure Ian will look into the other specifics you mention. Simon _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
