#287: make better use of existing build/failure reports (provide stats, alert authors) --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | --------------------------------+------------------------------------------- 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/maintainers (either via direct email or via a daily summary report on a list which all maintainers are subscribed to). 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.. provide 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.)? at the moment, i fully expect this to reflect just as many infrastructure issues as package issues, but that only makes it more important (it is hard to blame package authors if the infrastructure and dependencies keep changing under their feet, or if the tools keep them from providing failure-free packages). Ross provided these rough figures: .. 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. Duncan points out: 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 package. 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. http://hackage.haskell.org/trac/hackage/ticket/184 -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/287 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects