>> 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
_______________________________________________
Haskell-platform mailing list
Haskell-platform@projects.haskell.org
http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
