Hackage build reporting

[duncan]

Hackage has been enormously successful in terms of the number of packages now available. That growth has illustrated some problems. Now that there are so many packages, how do users know which ones to pick? How can they be sure that if they download one that it'll actually work on their system.

One solution might be to get the hackage server to build each package and report that on the website. Unfortunately this will not really scale, building packages takes too much cpu time to do on a single server and the server is not likely to have all the necessary C libraries installed. Also it is only a single sample of possible configurations of users machines.

Another solution might be to set up dedicated build-bots.

A more attractive idea is to allow anyone to do package build testing and to report that back to the hackage server. That way we get much more data than with a few build-bots and we get a much wider range of system configurations.

So the aim of this project is to get the cabal-install client to record the success or failure of each package built, along with some information about the configuration and to upload those reports to the hackage server. The server would have to store and aggregate the reports and derive useful information about each packages to display on the web pages.

•  ticket #184 - the build reporting feature request in the hackage trac

On the server side it turns out that there are many tasks that we might like to offload to trusted or anonymous clients (ie not just cabal-install), so we would really like a framework for managing reports. That would probably include a way of defining the schema of each report and versioning them. A simple example of a report might be a  http://www.dwheeler.com/sloccount/ sloccount] report where a client downloads a package, runs sloccount over it and reports the results. The server would add this information to the a package stats page. There are dozens of similar ideas for discovering useful information about packages, from simple things like sloccount to generating docs, running tests and code analysis.

So this project could either concentrate on the build reporting issue specifically or the more general reporting framework.

Interested Mentors

• Duncan Coutts

Interested Students

• Benedikt Huber

[guest]

Duncan says on the Hackage bug report that 'The remaining work is mostly server side.' In other words, the challenging work seems to have already been done, and this no longer seems like a 'Summer of Code'-worthy project. So I'm going to close this ticket. Someone may yet do the last work, but it shouldn't be a SoC project.