Excerpts from Don Stewart's message of Tue Jun 01 01:13:20 +0200 2010:

I see fairly regular complaints about too many Haskell libraries, bewildering choice of difficult-to-determine quality.

I want to send a small reminder that there was the idea adding a public wiki for each project which can react upon wishes of users faster than everything else: http://haskell.org/haskellwiki/Hackage_wiki_page_per_project_discussion Marc Weber

Forked to the Cafe... Hi all What's the procedure for marking one's own package(s) as deprecated on Hackage? Best wishes Stephen

Don Stewart wrote:

http://tinyurl.com/2cqw9sb

Thoughts?

Firstly, it pleases me that somebody is taking this problem seriously and looking at it. Currently all the information displayed on a package page comes from the Cabal file. I think it would be useful to be able to retrospectively alter certain things. (Information on stability, level of support, and platforms known to work / not work are obvious candidates here.) The package page really ought to be the central location for saying stuff about the package - and that includes information that becomes available after the package is released. We don't seem to have a comprehensive story for bug-tracking. Each project or library has their own ad-hoc arrangements. Usually that means no bug reporting system at all, although some of the larger projects each have their own seperate site. I think there is milage in setting up some kind of centralised system. Small projects probably don't merit the effort of setting up a whole dedicated tracker, and besides, who wants to create user accounts on a dozen different trackers? I'm thinking some kind of tracker which tracks bugs for any package on Hackage. Like, as soon as you upload a package, people can file bugs against it in one central location. (And check whether it's already been filed, for that matter...) Of course, it's not much use if it doesn't also notify the package author; presumably you have to specify contract details when you create a user account or something. It would also be nice to have a system in place for users to tell package authors about possible fixes / enhancements, etc. But given that everybody has their own favourit source control system (including NONE AT ALL) this isn't particularly easy. I guess we'll leave that for now. Also, unless I'm missing something, Darcs has a feature to run automated tests on commit, but there's no way of including a test framework in such a way that Cabal / Hackage knows how to test your package. The most it can do is test whether it compiles; it might fail spectacularly when actually *run*. (Also, end-users may or may not want this test infrastructure when installing a library.) Ooo, and change logs... There doesn't seem to be any coherant way to organise these. OK, so there's a new version of Foo out now. So... what's new? Is this a bugfix or does it have new features or just tweaked documentation or more QuickCheck properties or...? It looks like there ought to be a specific place to record this information. Documentation is something else worth looking at. Currently the Haskell Way(tm) is to have documentation embedded within the source code itself, which I've never been fond of. For one thing is makes the source about 20x bigger and obscures its structure with a lot of comments. But for another thing, there's more than one kind of documentation. Haddock handles API documentation. It is less than helpful for writing example documentation, introductions and tutorials, and all the other kinds of library documentation one might want to write. Also, it seems unfortunate that you have to edit source code and upload a new version of a package just to improve the documentation. What we do NOT want, of course, is documentation that's out of sync with the package it's supposed to document! Tying the documentation to the source code achieves this (mostly), but it seems like there should be a Better Way(tm)... I'm not sure what though. OK, I'm going to stop typing now...