[Haskell-cafe] expanded standard lib

[Duncan Coutts]

On Wed, 2007-11-21 at 10:59 +0000, Simon Peyton-Jones wrote:
> Some random thoughts triggered by this thread
> 
> 1.  I've been bowled over by the creativity unleashed by having a
> central site (Hackage), with a consistent installation story (Cabal),
> where you can upload packages with no central intervention.  A single
> issue of the Haskell Weekly (sic) News with 60 library announcements
> represents a qualitative shift from the Haskell situation 2 years ago.
> That is fantastic.

Yes, it's been amazingly successful. Partly it's new libs, partly it's
things that have been sitting around on various home pages or peoples
local disks. Both are great of course.

> 2.  We absolutely must not conflate GHC releases with QA-stamped
> library bundles.  The latter would be great, but the two must be
> separate.  (For reasons given by others in this thread.)

Yes or GHC HQ would go insane.

> 3.  I think it'd be great if there were bundles of libraries that work
> together, are available on multiple platforms, and have had some QA
> testing.  (Sounds as if releasing such bundles on a regular basis is
> the Gnome model.)  Its not clear to me that any one is actually
> volunteering to lead such a thing though.

At the moment I think it'd be too much effort so we're not likely to get
volunteers. However if we work on more hackage infrastructure I think it
should be possible to reduce the effort required to the point where it'd
be feasible. There is a separate discussion to be had about what kind of
QA standards we might want.

> 4.  Meanwhile, we could get a lot more mileage from de-centralised
> approaches.  Ideas I saw in this thread that sound attractive to me
> are to make Hackage display, for each package:
>   - date of last update
>   - download statistics
>   - some kind of voting scores, so users can vote for
>         good packages (and add text comments, please)
>   - auto-build system, so that there's a per-platform indication of
>         whether the package builds; ideally, packages should come with
>         a test suite, which could be run too
> 
> (Is this list complete?)

Those are the major things I think. We should file hackage feature
requests for each of them.

I'd also like to add links to darcs repos and possibly to bug trackers.
These are simple extra fields in a .cabal file that hackage can create
links for on the package page.

There is also the stuff about letting hackage document api changes by
comparing the apis of releases. This also relates to the package version
policy. It may be implemented via haddock.

> These things (or some subset) look more feasible to me, because they
> can each be done with a finite effort, and then computers and library
> users will do the rest.

Yes. I especially like the download stats and stats on development and
release activity, that should be easy.

For testing I'd like to see cabal-install report build success/failure
and have summaries of that information presented on each packages
hackage page. That's a slightly harder project. It should allow us to
gather an enormous amount of information however so it's probably worth
it.

Duncan