upgrading GHC

[Duncan Coutts]

On Thu, 2008-02-21 at 14:43 +0000, Simon Marlow wrote:

> I think doing this would deliver a system that "just works" for the 
> majority of users most of the time.  But it needs people to drive it and 
> make it happen.

In particular I think we need the infrastructure to keep the time
required by distro/platform maintainers to a minimum, otherwise it can
easily turn into a full time job.

I'd like to see an infrastructure where we can define subsets of hackage
packages using fully automatic quality tests. Then further subsets
defined by human review standards and consistent sets of packages that
are tested together.

All this testing etc is based on the idea that we have clients like
cabal-install (and other special-purpose clients) doing tests and
analyses and reporting back to the hackage server. The hackage server
should not be doing any heavy processing, just managing the information.

Here's a number of ideas for properties used to define hackage subsets:

      * can satisfy all of its dependencies from within hackage (there
        are a couple packages that depend on later versions of packages
        than exist within hackage)
      * package can actually build on at least some platform
      * package 'distcheck's ok, meaning can generate a tarball that
        builds
      * haddock docs build

These are all pretty basic.

For a platform release we want this property

      * all packages within the subset can satisfy all their
        dependencies consistently and can build against them

This is different from the first property, that a solution exists to
build each package individually, this requires that there is a solution
to build all the packages in the set using only a single version of each
package. Then further that this solution does indeed build.

Then for higher quality we also want:

      * builds on windows, linux, macos
      * builds with -Wall without too high a volume of warnings
      * follows the package versioning policy
      * uses bounded range deps for dependencies that follows the PVP
      * has sufficient haddock documentation
      * certain % test coverage and tests work

All of these can be checked automatically using suitable clients (mostly
extensions of cabal+cabal-install) and hackage reporting.

Some properties obviously require human review, like api quality, test
quality (as opposed to quantity). But if more packages can be filtered
down using these automated tests then putting together a platform
release becomes much more manageable.

Duncan