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.