I'm CC'ing John Peterson since he's one of the maintainers of the
haskell.org/libraries page and he hasn't made an appearance in this
discussion yet.
Manuel M T Chakravarty
(a) The current haskell.org/libraries/ page. Pros: we have got it Cons: developers cannot alter it themselves; we know it doesn't work
This begs the question of _why_ it doesn't work. All developers, or anyone else, has to do is email the page maintainers and they are pretty responsive in getting stuff onto the page. The fact that developers don't do this makes me think that the freshmeat solution (c) won't work. Just a guess. I think a static page, maintained with someone with both ears to the ground and a lot of interest and curiosity (did someone mention Shae?) makes the most sense, except for the poor soul who has to run out there and collect, collate, and maintain the information himself.
(b) The wiki page Pros: Easy to edit for everybody; exists already Cons: Developers need to use the wiki (not hard, but probably a hurdle for those who have never done it); free form style of wiki is more work to edit and a common format must be maintained by convention
This is indeed a nice solution, since Shae-type characters can edit the page and library authors can add their own stuff. Other cons include temporary unavailability due to SPAM, and maybe some other trust issues wrt anyone being able to edit the pages. I don't think those are very important, personally. I might change my mind the first time I see a trojaned version of cabal or something appear there, and have someone claim that they downloaded it from an official Haskell site.
(c) freshmeat.net (snip)
(d) Develop a user-updateable database for haskell.org Pros: custom made; easy to edit, little work to keep entries up to date Cons: Somebody has to implement it; it's been proposed before and not done
This is my favorite solution, and I think it will eventually be done, but I completely agree that we need something in the meantime. I'm much more interested in finishing Cabal (the building & registering part) before moving on to the rest of the Infrastructure (the listing and distributing part).
I am strongly against (a) and (d). Alternative (a) is bad, we know that. Alternative (d) is vapour-ware and we need something working now.
I won't discourage anyone from working on a (d)-type solution layered on Cabal, except to the extent that Cabal is still in the alpha stage and will likely change. Some people have been more interested in this part than the building & registering part, and I would encourage them to take a look at Cabal in the state it's in and maybe hack up some prototype and tell me where Cabal needs to go in order to support the listing & distributing part: http://www.haskell.org/cabal
Besides (d) is going to need a maintainer and I think we can use our time for better things.
If you see (d) as being a part of a package distribution architecture like CPAN, then I feel this is actually one of the most important things we could be working on right now. (snip)
Personally, I would tend to go with the wiki as The Haskell Libraries Page, but encourage people (at least for larger projects) to add freshmeat entries, which are then linked from the wiki.
Sounds good to me. peace, isaac