GSoC Student Guidance and Project Ideas for 2016

/!\ Please see also our SummerOfCode/2016 page, which contains additional information for GSoC for this year.

1. About Mercurial

2. Contacting the Mercurial developers

The following channels are used by default for communication. Please use them to introduce yourself!

3. Getting started/Candidate checklist

All candidates should do the following before completing their application:

  1. Check the SummerOfCode/Ideas2016 page

  2. Subscribe to this page to get email when it changes

  3. Introduce yourself on IRC

  4. Introduce yourself on the mailing list

  5. Read the ContributingChanges pages.

  6. Look at the easy bugs list and contribute a patch. Feel free to ask questions on IRC or the mailing list while getting started!

  7. Follow the steps to apply: check the application checklis and submit your application.

  8. Add yourself to the SummerOfCode/Candidates2016 list, so we can have an early view of how many candidates there are.

4. Things we look for in a candidate

5. GSoC ideas

Here are some ideas of possible 2016 summer project ideas for Mercurial. Your own ideas are welcome. You may decide to work on these ideas or use them as a starting point for your own.

5.1. Example Project

5.2. Moving toward Python3

5.2.1. Project description

Mercurial currently only supports Python 2. We'd like to improve Python3 support, but that will require a lot of work. A large amount of the work is relatively simple. Some of the first tasks needed will be:

Further (also more difficult) tasks are listed on the Python3 page, but the above will most likely take up quite a bit of time already.

5.2.2. Project properties

5.3. Improve commit graph in hgweb

5.3.1. Project description

Current graph rendering code in hgweb is pretty clunky and not very extensible or efficient. We could update it to use hgweb's own JSON API, to be faster and smarter, to show more things and to look nicer. You can see an example of the current hgweb interface at the Mercurial's main repo. This task can vary a lot depending on your own preferences, as you can do quite a few different subtasks.

More ideas and visual decisions could be borrowed from TortoiseHg, Bitbucket and Kiln.

5.3.2. Project properties

5.4. Implement templating for more commands

5.4.1. Project description

The hg log subcommand has a flexible templating language. Its flexibility allows creating custom commands or providing guaranteed output for tools. One example is using hg log --template "{node}\n" to see the full SHA-1 hash of a changeset. Another example is using templates (in combination with other features like revsets) to create useful and completely customized output for all changesets currently being added by a developer/user.

Currently, the --template parameter is fully supported only by the log command, but many others could benefit from using the template language as well. This could be very varied, for example adding full template support to summary or identify. Commands like bookmarks and blame already have an experimental --template argument and can use the template language, but they have a very limited set of template keywords.

This proposal consists of two major parts:

5.4.2. Project properties

5.5. Allow largefiles to be at a different location

5.5.1. Project description

Mercurial has a feature called largefiles, which allows storing large files outside of the normal history (more details, see LargefilesExtension). Currently, largefiles must be stored in the same location as the main hosting server.

The goal of this project would be to: 1. allow the user to change the location (to say, a central file server for a team) 2. allow the server to send a url (with an authentication token) to the client that would tell the client where to push the largefile.

A number of possibilities is available for this. For example, it would be possible to add a new server 'capability', so clients know this server supports a new location for storing largefiles. Alternatively (and preferred so far in developer discussions), a concept called PushkeyConcept could be used. This concept allows Mercurial to send additional key-value pairs with extra information (in this case using a 'largefiles' identifier.

This project will also involve quite a bit of discussion regarding the design with the Mercurial developers.

5.5.2. Project properties

6. Other ideas?

Come talk to us on IRC.


SummerOfCode/Ideas2016 (last edited 2017-01-20 04:06:31 by timeless)