[Hackage] #287: make better use of existing build/failure reports (provide stats, alert authors)

[Hackage]

#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