Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
GSoC 2014 proposal
This is a copy of Chris Wong's GSoC proposal for the hackage-server. This project has been accepted and is currently in progress. See Chris's blog for updates.
The new Hackage offers many novel features: package candidates, custom documentation, build reports, even a rudimentary tag system. However, often these are not used to their full potential – they are either difficult to use, not exposed in the interface, have outstanding bugs, or some combination of the three. This project aims to finish these features, so they are stable and useful to the community.
What is the goal of the project you propose to do?
The new Hackage offers many novel features:
Package candidates: maintainers can upload and test a package without publishing it;
Custom documentation: if a package cannot be built on the server, users can build and upload documentation themselves.
Build reports, generated by both Hackage build bots and users.
A rudimentary tag system, including the ability to browse by tag.
However, often these are not used to their full potential – they are either difficult to use, not exposed in the interface, have outstanding bugs, or some combination of the three.
This project aims to finish these features, so they are stable and useful to the community.
In what ways will this project benefit the wider Haskell community?
Everyone who uses Haskell also uses Hackage, in some way or another. It is clear that these improvements will benefit the community as a whole.
Can you give some more detailed designs of what precisely you intend to achieve?
The issue tracker on GitHub already gives a broad impression of what is to be done. Most of the project will consist of fixing the issues listed there.
Build reports for package candidates (#74).
Expose these reports in the interface (#37). A “build status” field in the package properties, with a link to the latest report, could be a good first step. Next would be a human-readable list of reports, to replace the existing mess.
Allow users to upload their own logs (#44). As Duncan Coutts points out, we need to be careful about keeping these reports anonymous. Further discussion should make this issue more clear.
see #56. To make this usable, we need to:
Expose doc uploads in the HTML interface, with instructions on how to generate the required tarball.
If there is extra time: add a command to cabal-install (cabal docdist?) to build it automatically. There already exists a script with this functionality (see the issue comments); we can base the extension on that.
Package candidates: the issues listed in this comment.
Tag system (if time permits)
Make it easier to tag packages. Currently tagging is restricted to the package maintainer – expanding this to all verified users is a possibility.
What deliverables do you think are reasonable targets? Can you outline an approximate schedule of milestones?
This project is quite flexible, since each feature can be worked on independently. Hence at this stage, little needs to be set in stone.
Research & Planning (April 21 ~ May 19)
I’ll also plan out what to do in the later phases – mockups and blog posts are a possibility – and solicit feedback for these plans.
By the end of this period, I will have a good idea of what improvements are to be made, and how to perform them.
Coding (May 19 ~ June 15)
Coding begins. I will first work on exposing build reports and doc uploads, since these seem to be the most pressing; and hope to have these ready by the end of this period.
Exams (June 16 ~ June 28)
Coding, part 2 (June 29 ~ August 11)
Here I’ll fix the issues related to package candidates. Any remaining time will go into exploring other ideas, including the cabal-install command.
Wrap up (August 11 ~ August 18)
Write documentation, announce project on Reddit, party.
Many thanks to Mateusz Kowalczyk for feedback and ideas.