Michael 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 Simon From: Michael Snoyman [mailto:mich...@fpcomplete.com] Sent: 05 June 2014 17:10 To: Simon Peyton Jones Subject: GHC/cabal release procedures, and Stackage Hi Simon, 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? Thanks, Michael 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.
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
