make better use of existing build/failure reports (provide stats, alert authors) #280

bos opened this Issue May 24, 2012 · 1 comment


None yet
2 participants

bos commented May 24, 2012

(Imported from Trac #287, reported by guest on 2008-05-30)

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.


tibbe commented May 5, 2014

Closing as there's been no activity in years.

We're cleaning up the bug tracker to make it useful again and are thus closing bugs that haven't seen any activity in a long time. Please re-open (or file a new bug) if the problem reappears.

@tibbe tibbe closed this May 5, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment