Windows installer 2010.2.0.0 RC1

[Claus Reinke]

>> More generally: what is the status of establishing a
>> proper testing process for Haskell platform releases?
> 
> Currently we have an ad hoc process:
> 
>    * GHC people test and release as stable version
>    * Package developers release new stable versions
>    * We adopt the new packages and GHC based on the PVP.
>    * Each distro maintainer packages the specification set, and adjusts
>        for any bugs
>    * Once Unix, Mac and Windows installers are signed off, after 2 or 3
>      RCs, we do the release.

Two immediate questions come to mind:

1. While it is great that distro maintainers are willing to 
    "adjust for any bugs", wouldn't it be preferable to see
    them as "interface guardians", making sure that the
    HP components "just work", in isolation and together? 

    They would act as clients for all the HP components, 
    provide feedback to the component maintainers and 
    -most important- are available as someone who can 
    test suggested fixes on their platforms (frequently a
    problem for package maintainers).

    But the component maintainers keep the responsibility
    for fixes; if the distro maintainers can send patches, all
    the better, but at the end of a release cycle, every 
    package/component of the HP should have a matching
    version (which may or may not exist before the HP
    release process) which is known to build on each HP
    platform, and work with all other HP components.

2. Is there a checklist for distro maintainers and release
    candidate testers, about what to check? 

    Starting a (small) testsuite might help - distro maintainers 
    could run that on any new component versions, to check 
    whether anything breaks before the next HP release
    cycle begins, release candidate testers could run it
    to provide feedback to distro maintainers. And 
    component maintainers of HP components could
    run the testsuite to see whether their new component
    releases are going to run into trouble for the next
    HP release cycle.

In other words, instead of the HP distro maintainers
taking what is there and trying to make something work
whenever the time comes, the focus would shift towards
keeping a working target set, and alerting component
maintainers of regressions and integration issues, so 
that the release cycle itself could be simpler.

> An automated way to track the RCs and sign-offs would be great.

I thought I heard somewhere that newer versions of trac
supported user-defined workflows (GHC folks were also
planning to look into testing this, I think).

Claus