Hackage rough To Do list

• Show who uploaded package and when
• auto building
• The page for a package could include information from standard README, INSTALL, NEWS etc files.
• Those files could contain wikitext-like markup.
• Syntax highlighted source code with links from haddock directly to function definitions
• The package page could have links to other versions of the same package, and maybe to packages which depend on it?
• Darcs URL and instructions for packages with darcs repos.
• Possible darcs integration, with change logs etc.
• Generate change information between package versions: functions added/removed/changed, modules added/removed.
• When a new version of a package is uploaded, generate a list of packages that will be affected and possibly broken by the upload, and notify the uploader, and test the builds.

Rough plan for Haddock

• The generated haddock should link to types, modules etc. in the packages which it depends on.

• The Haddock for the latest version of each package is in a known place.
• Links across packages always point to the latest version of the target package. This way we don't have to worry about re-haddocking dependent packages whenever a package at the bottom of the tree is updated. Some dependencies may go wrong, if a package depends on a specific version of another package for example, but this way is simple at least.

• Avoiding running arbitrary code to generate the Haddock: if we restricted ourselves to packages that just use the simple build system and only Haddock those, then we don't need to worry about arbitrary code. But some important packages use autoconf, and we won't be able to do those. Also, we can't tell whether a package uses the simple build system or not: we need the field in the .cabal file to tell us (see previous discussion).