[Haskell-cafe] Re: GSoC: Hackage 2.0

[Maciej Piechotka]

On Wed, 2010-04-07 at 00:40 -0400, Matthew Gruen wrote:
> Hi Haskellers,
> 
> I'm Matt Gruen (Gracenotes in #haskell), and the Hackage 2.0 SoC
> project at <http://hackage.haskell.org/trac/summer-of-code/ticket/1587>
> really piqued my interest. It seems doable, in a summer, to make the
> new hackage-server more-than-deployment-ready as well as clearing out
> some items in the hackage bug tracker[0]; so, I've been working on a
> proposal. In this email I'd like to consolidate my mental notes for
> haskell-cafe and formulate a roadmap towards a more social Hackage.
> 
> The most vital part is getting hackage-server
> <http://code.haskell.org/hackage-server/> to a state where it can be
> switched in place of hackage-scripts
> <http://darcs.haskell.org/hackage-scripts/>, and doing it properly,
> organizing the code so it can be extended painlessly in the future.
> Duncan Coutts, Antoine Latter, and others have done some great work on
> it in the past few years. I've been using Haskell for 1.33 of those
> years. I think I could become fluent in the codebases after a week of
> dedicated study, although even the hackage-server and hackage-scripts
> repositories don't include some components such as the current build
> report script.
> 
> For putting the 2.0 in Hackage 2.0, any interface changes should help
> the library users and the library writers/uploaders without hurting
> either of them. Hackage should contain more of the right kind of
> information. Statistics help everyone, and they're a pretty good gauge
> on the direction of Hackage as a whole. Package popularity contents
> are one form of this. Reverse dependencies and even dependency
> graphs[1] are great, if I can integrate and expand Roel van Dijk's
> work[2].
> 
> There should also be some space on package pages, or on pages a link
> away from them, for users to contribute information and suggestions.
> Coders can explain why or why not the package met their needs, as a
> sort of informal bug/enhancement tracking service. Another helpful
> flavor of information is package relationships beyond dependencies:
> 'Deprecated in favor of Foo', 'a fork of Foo', or 'does blah instead
> of Foo's plugh functionality'. This will help people find the 'right'
> package among look-alikes. There could also be links to illustrative
> usage examples for getting started. Happstack's state management will
> be a good match for updating and serving this information in real
> time.
> 

I guess 'works also with B in version X.Y.Z' is also. Most of the above
changes should not be IMHO in cabal (sorry for answering PS here).
Especially 'not maintained anymore' and 'does not build on recent
GHC' ;)

> There's also a need for a more interactive form of package
> documentation, but this should strengthen relationships with existing
> tools like Haddock and Cabal, not bypass the tools. For example,
> adding a changelog[3] or making Haddock's declaration-by-declaration
> commentary more wiki-like[4]. Changelogs seem to be within the scope
> of Hackage 2.0, integrating with Cabal; Haddock wikification might not
> be, perhaps deserving a separate student-summer session of its own.
> These can improve the package page and documentation subtrees.
> 

As we are with Haddock - 'rebuild' button if package failed to build?
For some reasons some packages fails to build on hackage (as yi). I'm
not sure if it will work however. At least uploading docs should be
possible.

Regards

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20100407/ad539dc9/attachment.bin