hackage, package list, trac, some suggestions/questions

Duncan Coutts duncan.coutts at worc.ox.ac.uk
Fri May 30 16:52:03 EDT 2008

On Fri, 2008-05-30 at 15:23 +0100, Claus Reinke wrote:
> 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;-)

We used to have that and got horribly spammed. Apparently for the ghc
trac they've worked out how to do that without getting spammed so
presumably we could do the same.

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

Yeah, I always use my browser's in-page "just start typing" search.

The longer term plan is to use hoogle as the primary interface so it can
search on package name, package meta-data and of course the content, api
and docs.

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

It's harder than it looks. The build results from the server builds
itself are not very accurate reflections of the real status. That's
partly why we do not yet attempt to email maintainers about the results.
For example the fact that the build server does not have most C libs
installed means that lots of FFI binding packages and all their
dependents fail. It also suffers from the diamond dep problem. Also it
only reflects one particular operating system and configuration of each

The plan is to get build results from users. Though then we have to do
some statistical analysis to discover if a package works with various
versions of compilers and on different OSs etc.

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

That's the kind of information we should be able to gather once we have
clients report build results to the server.

> 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

I'd tend to disagree. I think it's better for authors/maintainers to
make releases on hackage when they think it's right.

>     - the maintainer email on each hackage package page
>         ought to be
>         (a) protected, not plain text

Would you like to file a ticket about this.

>         (b) annotated with last successful contact date

Hmm, how do you think that'd work? Sounds tricky to automate. Anyway, we
rather hope that it is the author themselves or their delegated release
manager who are making the releases so there's no need for a system to
automatically contact authors.

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

We generally hope that it is the author that is uploading their package.


More information about the Libraries mailing list