GSoC Student Guidance and Project Ideas for 2018

/!\ Please see also our SummerOfCode/2018 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/Ideas2018 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 checklist and submit your application.

4. Things we look for in a candidate

5. GSoC ideas

Here are some ideas of possible 2018 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. Improve commit graph in hgweb

5.2.1. Project description

While hgweb is the web UI that comes together with Mercurial and so is readily available to every user, it somewhat lags behind in presentation. You can see an example of the current hgweb interface at the Mercurial's main repo.

This project focuses on graph rendering in hgweb, because seeing the DAG can be very useful and because there's plenty of ideas on how to improve it. We could make it faster and smarter, show more things, and look nicer. Here are some ideas, but not all of them are required, and more ideas can be added in the process if everyone agrees on them.

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

5.2.2. Project properties

5.3. Add dry-run functionality to each commands

5.3.1. Project description

There are some write commands which have a --dry-run flag which tells user what will be the results of the operation without doing that. For example hg revert --dry-run.

This project focuses on adding the --dry-run flag to write commands which are good candidates like phase, strip, pull, push, amend, graft, merge, rebase, histedit. In case of rebase, histedit, graft, prints out the graph that would result if we ran the command.

Bonus points if we can have a --confirm flag too. Difference between --dry-run and --confirm:

5.3.2. Project properties

5.4. Improve the functionality of `hg grep`

5.4.1. Project description

This project aims to improve functionality of hg grep command. Right now behavior of the command is ambiguous, undocumented and not what people expect mostly. We need to improve the functionality of plain hg grep and hg grep --all. To see what both of them do right now, look for GrepPlan.

Here are some tasks which needs to be done as a part of the project:

For more information GrepPlan.

5.4.2. Project properties

6. Other ideas?

There are more things on WeShouldDoThat which we will like someone to work on. You can pick an idea from there too.

Come talk to us on IRC.


CategoryGsoc CategoryGsoc

SummerOfCode/Ideas2018 (last edited 2018-03-19 06:59:41 by PulkitGoyal)