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