hackage, package list, trac, some suggestions/questions

[Ross Paterson]

On Fri, May 30, 2008 at 03:23:06PM +0100, Claus Reinke wrote:
> 1. hackage trac does not seem to have a "register" option
>     (compare hackage trac with ghc trac). individual logins
>     are nice because:
>     - gives individual rather than anonymous reporters
>     - one place less to support spam email harvesters
>         (account name instead of full email address)
>     - "register" is always there, hence easy to find, unlike
>         the hint hidden on the trac home page that hackage
>         is still abusing the haskell' trac.. (i had started this
>         email before i found that hint;-)

Yes.  In the meantime, feel free to file feature requests as guest.

> 4. is there an cross-package index of builds/failures, so that
>     one might see trends (cabal issues, base package issues,
>     bytestring issues, next big thing issues,..) and statistics
>     (how many hackage packages fail/build, which compiler/
>      cabal/haddock versions are successful for the largest
>      number of packages, etc.)?

No, but here are some rough figures on failures (for the latest version
of each package):

  7 configure: prerequisite packages missing or not built
 22 configure: other (usually a custom Setup.hs)
  6 build: header file for some C library not found on the build system
 46 build: a package dependency was not listed (often a base split issue)
 14 build: a module was omitted from the package
 38 build: other
 22 haddock failure
  4 install failure

It is surprising how many would surely have failed on the maintainer's
machine if they had been tested.

> 5. generally, i've always thought that hackage works the
>     wrong way round; instead of yet another push-based
>     place for people to put and forget copies of things, it
>     should work as a pull-based cache:

It's a place for maintainers to put their releases (there may not even
be a another place to pull from).  It seems to me entirely appropriate
that maintainers should assume responsibility for that.

>     - the maintainer email on each hackage package page
>         ought to be
>         (a) protected, not plain text
>         (b) annotated with last successful contact date

The email address on the package is merely copied from the .cabal file,
which is also publically available.  If a maintainer wants to hide this,
they need to obfuscate it in the .cabal file.