-
Notifications
You must be signed in to change notification settings - Fork 197
GSoC 2014
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.
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.
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.
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.
-
Make tags searchable and coalescable (#27, #24). As a corollary, we should also make tags case-insensitive.
-
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.
Here I get acquainted with the mentor, and poke around the Hackage code. I may write some small patches (#124, #184, #201), to help understand the structure of the server.
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 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.
Here I’ll fix the issues related to package candidates. Any remaining time will go into exploring other ideas, including the cabal-install command.
Write documentation, announce project on Reddit, party.
Many thanks to Mateusz Kowalczyk for feedback and ideas.