hackage, package list, trac, some suggestions/questions

[Claus Reinke]

hope this is the right list for hackage issues?-)

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;-)

2. the hackage package list ought to have a link to an
    alphabetical index (i often know the package name, but
    not the likely categories, so i tend to 'search' on that
    page..).

3. the hackage package list ought to list successful and failed
    builds (simply a list of compiler versions, each one green
    or red, depending on success, with direct link to build/
    failure log; this would fit into the one-line-per-package
    format) for each entry, and report them to package authors.

    build failures currently seem to be created automatically
    where package authors may not notice them? at least,
    that would explain things like (just examples of things i
    happened to have looked at, no offence intended;-)

        - hint: advertised to work with ghc 6.8.x on the same
            package page that lists a build failure for ghc-6.8
        - haskell-src-exts: lists a build failure for ghc-6.8

    the first is probably a too optimistic cabal version
    spec, the second is a haddock issue. but that makes
    two out of two for package i looked up recently..

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.)?

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:

    - author registers package, with author/maintainer
        email and package url
    - hackage retrieves package, tries to build, and either
        accepts or not, reporting all to author
    - occasionally, hackage scans for new versions to
        be retrieved, again notifying authors of uploads
        and problem reports
    - the maintainer email on each hackage package page
        ought to be
        (a) protected, not plain text
        (b) annotated with last successful contact date

    if i understand #243, authors are not even notified
    when someone uploads their packages?

claus