Important dates

  • March 16-27: student application
  • April 15: slot allocations is published
  • April 27: confirmation of accepted student proposals
  • May 25: gsoc beginning
  • June 26-July 3: midterm evaluation
  • August 21-28: final evaluation

What this is about

The Google Summer of Code (GSoC) is a program that helps students getting an experience of contributing to some free software project. Darcs has been participating for several years to this program as a way to 1) enable existing contributors to dedicate fully to darcs for a few months, and also 2) enable students to have an experience in a free software organization.

Check out the student guide to know what you’re getting into.

Project ideas

Here are some ideas for 2015 Google Summer of Code student projects. Note that these themes are just to get you started. We welcome submissions beyond these initial ideas. Get in touch with us! or #darcs on freenode.

All of these projects require good Haskell skills. We trust and appreciate students who have contributed to darcs before applying :-)

1. HTTP system overhaul

Currently Darcs depends by default on the C library curl to handle file download by HTTP. Alternatively, it can depend on the Haskell library HTTP.

We would like to experiment switching to wreq. This would involve having wreq as the default download system. We might keep the current libcurl and HTTP code for benchmarking purposes, but given its rather complex interface it may be simply better to replace it entirely and benchmark against darcs pre-replacement.

It might make sense to deliver this as an independent “download manager” library. This would encourage a clean design that’s not too coupled with darcs, and potentially be of benefit to the Haskell community as a whole.

The benefits would be:

Deliverables (apart from the code itself):

  • HTTP benchmarks (wreq vs libcurl vs HTTP)
  • testing that pipelining actually works
  • testing under windows / linux

Darcs does not currently send any file by HTTP but if we enable HTTP push it would be nice to benchmark HTTP send anyway.

2. Friendlier Darcsden

We have various targets to make Darcsden easier to install and use.

  • plain files backend (vs current CouchDB)
    • desired outcome: Darcsden easier to deploy locally, with acceptable performance under low traffic
  • unauthenticated patch submission via darcs send and http:
    • can/should be unauthenticated or require an account on darcsden?
    • how should submitted bundles be presented to the repository owner?
    • how does darcs detect that it should send to darcsden instead of doing a regular send?
    • desired outcome: easier way to contribute to a darcs project without having to configure sendmail
  • http push (to darcsden):
    • specify how darcs could push to a dumb server (without remote darcs), for instance via ssh
    • pushing to a dumb server requires changes in the working of push. this requires local darcs to download more files and do the merging work locally.
    • it would be useful to measure the tranfer costs of pushing to dumb server vs. pushing to server with remote darcs vs. pushing to a repository inside of a locally mounted sshfs folder vs the dumb way (clone local, pull from remote patches from it, delete remote repo, clone merged repo to
  • enhancing easiness of retrieving source code from darcsden without having darcs:
    • a “Download ZIP” button, similar to github, using the darcs dist --zip feature
    • automatic creation of git mirrors? (stretch goal)

3. Better conflicts handling/UI

Proposed by/willing to mentor: Ganesh, Guillaume

  • Improve the representation of local conflict markers in the working directory - e.g. make it possible to obliterate the patch causing the conflict and get back to the original local changes

  • avoid invisible conflicts
  • easy way to find out which patches conflict with which
  • more precise conflict reporting
  • Unresolved conflicts-related issues in the bug tracker

  • Improve fast-export with regard to conflicting patches. Because of how darcs handles conflicts, some information can be lost with the current way of creating incremenal mirrors to git (with convert export). An approach to address this would be to only resume exporting when the source repo is in a non-conflicting state (to at least have a history log that is faithful to the source repo). We could warn users about conflicts. Or maybe we can export all conflicting patches in some way, into the git mirror repository (branches?). See previous discussions on this topic:
  • What about darcs-1 semantics?

  • See also page 10 of Ganesh’s talk

4. Use darcs as a conflict-resolution tool for any VCS

Proposed by/Willing to mentor: Ganesh

Resolving conflicts during a merge in any VCS involves (at least implicitly) reconstructing the semantic intent of the changes on each side, and then applying them on top of each other.

Darcs patches are a great way of expressing semantic intent explicitly. Build a tool based on darcs patches where the user can reconstruct the changes for both sides of the conflict as a chain of darcs patches, and then use the darcs merge result to actually resolve the conflict (or at least cut it down). As well as the existing darcs patch types, this offers a lot of scope for adding new types just for the tool, as we won’t need to worry about the usual backwards compatibility concerns - for example it might try to parse the changes as source code. The tool can also try to automatically infer the patches as well as allowing the user to enter them explicitly.

5. Develop darcsden as a local darcs UI

Proposed by/willing to mentor: Ganesh

Darcsden is currently primarily focused on being a multi-user, server-based tool for hosting darcs repositories. However there’s a lot of overlap with local manipulation of a darcs repository on a workstation. Extend/generalise Darcsden so it can be used for both.

This probably involves modifying darcsden so that it uses plain files instead of a database backend.

6. Distributed issue tracking for darcsden

Proposed by/willing to mentor: Ganesh

Change the darcsden issue tracker to store the issues themselves in a separate darcs repository. Other people have tried distributed issue tracking before so this also involves investigating previous solutions.

7. Better patch dependencies

Proposed by: Florent, Ganesh, Guillaume, Owen

  • show on whatsnew and record on which changes do the unrecorded changes sit
  • automatically discover patch dependencies (amend --ask-deps) when given test fails without them
  • visualization of patch dependencies

8. Other projects

Keep in mind that you could always propose an project with a whole different set of ideas. Be creative! :-)

Other project ideas:

Application process

  1. Sketch out an idea. Can you make Darcs faster? Can you make it more useful? It would make sense to get in touch with for some help.

  2. Get in touch with the Darcs team if you have not done so already

  3. Write up your proposal (this should take a day or two). See the previous applications if you’re having trouble getting started.

  4. Submit your application to the GSoC website Register as a student first then submit your application.

Older projects

  1. 2014
  2. 2013
  3. 2012
  4. 2011

  5. 2010

  6. 2009 - Hashed storage (Petr Rockai)

  7. 2007 - Darcs 2 research (Jason Dagit)

See also