GHC/cabal release procedures, and Stackage
Simon Peyton Jones
simonpj at microsoft.com
Fri Jun 6 12:37:19 UTC 2014
I think that would be great. Absolutely: the earlier we can catch regressions the better.
Couldn’t we make it part of the continuous-integration builds (Travis?) that various folk are running, eg. Joachim?
I’m hazy about how all of this works, but I’d love it just to happen automatically every night or whatever, with failure being reported by email, with instructions on how to reproduce the failure.
Might you work with Joachim and others to make that possible?
Thanks for suggesting it
From: Michael Snoyman [mailto:michael at fpcomplete.com]
Sent: 05 June 2014 17:10
To: Simon Peyton Jones
Subject: GHC/cabal release procedures, and Stackage
I wanted to bring up an idea I've been playing with for a few weeks now. The past few releases of GHC and cabal-install have introduced regressions that were not caught by test suites, but were caught by building code from Hackage. In particular, I discovered some of these bugs almost immediately after release by doing normal Stackage builds.
So I'd like to propose that part of the GHC and cabal-install release processes include trying to run a build of Stackage. This should be both a good stress test, plus- since Stackage covers the majority of actively used packages- should also be a good indication that early adopters of the new version won't immediately hit bugs.
I'm happy to volunteer to be a part of this process (e.g., to be the guy who actually runs the builds). As a user, I'd definitely appreciate the opportunity to iron out bugs before they hit the light of day and start causing larger headaches. What do you think?
PS: A relevant issue is an upcoming yesod-bin breakage in GHC 7.8.3: https://github.com/yesodweb/yesod/issues/748. I haven't been able to investigate this myself since there seems to be a build bug for 7.8.3 when using the Gold linker.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs