Status updates

[Herbert Valerio Riedel]

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