On 2014-04-22 at 14:42:46 +0200, Austin Seipp wrote: [...]
- I've been looking into our CI setup for GHC, and evaluating things. Right now though, I am directly working on getting Windows build bots set up on Gabor's infrastructure. He gave me the credentials, and hopefully this should not take long, it just slipped my mind.
But mostly I've been looking at CI systems for Hackage, so that we can try to continuously integrate a subset of important packages against GHC over time. Right now, we have Travis-CI thanks to Herbert, but not quite everyone uses this (or doesn't properly configure it to e.g. test HEAD).
This would really help find things in the future, I think, especially closer to release. It would also really help find nasty bugs in the RCs, like the dreaded #8978
Right now, after some thought, I'm looking into Michael's Stackage as a starting point for this, as he's done some awesome work. But I haven't yet done so in anger, and there are some other things I want to try too.
I want to add that a GitHub-integrated CI like Travis-CI and a "Hackage-CI" are two different CI-systems that complement each other, in case there may be the impression that one renders the other one redundant. Something like Travis-CI helps a package maintainer keep the HEAD branch from breaking early during development even before the package is actually uploaded to Hackage (furthermore, it helps pre-validating patches in pull-requests so might save the package maintainer time with patches that don't pass the test-suite). Whereas a build-the-world Hackage-CI would (the way I understand it) help detecting that the Hackage *released* package-set is in a working state for a given compiler configuration (including GHC HEAD[1]), w/o any active cooperation from the package maintainer. And more importantly, it may trigger rebuilds of depending packages, when new packages is added to the Hackage index to help detect problems due to inter-package interactions. [1]: However, I wonder how to keep Hackage buildable with GHC HEAD w/o having to patch up every package that will likely break sooner or later due to API (e.g. the AMP-refactoring will likely break stuff) and compiler changes[2], as I don't think cabal-install's --allow-newer will help in all cases. [2]: This already happened due to #8883 with the HTTP package, see also haskell/HTTP#58 Cheers, hvr