GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
(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;-)
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.
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.