[Haskell-cafe] Recompiling Hackage to estimate the impact of a change [Was: StricterLabelledFieldSyntax]

[Don Stewart]

johan.tibell:
> 
> In general, I think it would be a good idea to provide some statistics of how
> many packages would break as the result of a backwards incompatible change.
> Without that data I find it hard to do a cost-benefit analysis. So I hereby
> suggest that we make a recompile of Hackage a requirement for any breaking
> language changes. I understand that it might not be that easy to recompile all
> of Hackage at the moment so we should try to come up with some step-by-step
> instructions on how to do it. In the future it would be nice to have a little
> script that does it and spits out some statistics.

Agreed. And it should be required as part of release processes for GHC.

Duncan has described the process of building large amounts of Hackage,

    http://blog.well-typed.com/2009/03/regression-testing-with-hackage/

We used this prior to the ghc 6.10 release to find a few interesting
type system bugs, and get in steps for what breaks and why, ultimately
easing the upgrade process so that it affected only a couple of percent
of packages.

So, +1, let's take advantage of this centralization to improve overall
quality standards.

-- Don