GSoC Student Guidance and Project Ideas for 2017

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

1. About Mercurial

• What is Mercurial? Mercurial is a free, distributed source control management tool. It efficiently handles projects of any size and offers an easy and intuitive interface.

• Why is it interesting? Besides the extremely good reasons just above, Mercurial is also interesting for many other reasons, including: a great extension system, excellent backwards compatibility, excellent documentation, ... Specifically for students, it's interesting because it offers a range of topics to work on from low-level speed optimizations all the way up to a web interface.

• Who uses it? Mercurial is used by individuals, organizations and companies all over the world. The same goes for contributors: in the open source community, a well-known organization using Mercurial is the Mozilla project, but companies like Facebook, Google and many others also contribute to Mercurial.

• What language is it written in? Mercurial is mostly written in Python. We rewrite some parts that are very performance-sensitive in C.

2. Contacting the Mercurial developers

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

• IRC: many developers chat and discuss planned changes to Mercurial here. Keep in mind that most developers are in US timezones, so it might take quite a bit of time (hours) to get a response outside of those timezones!

• The developer mailing list: this list is mostly used to submit patches and discuss them.

3. Getting started/Candidate checklist

All candidates should do the following before completing their application:

1. Check the SummerOfCode/Ideas2017 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.

4. Things we look for in a candidate

• Demonstrates understanding of our tools, procedures, and source code by successfully submitting patches (see last step above)
• Participates in the community, especially via IRC
• Makes a commitment to work on GSoC full-time
• Gives an indication that she or he enjoys working with Mercurial enough to become a long-term contributor, after GSoC is over.

5. GSoC ideas

Here are some ideas of possible 2017 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

• Project description: This is an example project. Please add a clear description with some details about the idea.

• Skills: Specific programming languages, domain-specific knowledge... For example: Python, network programming

• Difficulty level: Easy/Intermediate/Difficult

• Related reading/Links: Useful links to wiki pages, specific relevant mailing list discussions or patches, ...

• Further details: Additional detail about the idea

• Point of Contact: Who wrote this proposal and could answer question about it.

• Potential mentors: mentors likely to be involved with this project

5.2. Improve commit graph in hgweb

5.2.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.

• Think up a good (extensible, self-descriptive) format for graph data to put into JSON and implement it server-side
• Update client-side code to use JSON for initial rendering and rendering on scroll-down ("infinite scroll")
• Make client-side code to render graph in chunks (will help with performance after a number of infinite-scrolls and will solve issue4020)

• Maybe use SVG instead of <canvas>

• Add (non-public) phases to commits in graph (next to branches, tags and bookmarks)
• Display special (e.g. branch-closing) commits in a different way
• Display special edges, such as source-destination of a graft
• Add an ability to see obsoleted changesets (including obsolescence edge)
• Show faded-out edge(s) from the nodes on the top of the screen if they have children (e.g. when tip is not the topmost graph node), this is already done for nodes with parents at the screen bottom

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

5.2.2. Project properties

• Skills: Python (server-side), JavaScript (client-side)

• Difficulty level: Intermediate (but can become more difficult if you can take up some of the more complicated subtasks)

• Related reading/Links: https://bz.mercurial-scm.org/show_bug.cgi?id=4020 https://bz.mercurial-scm.org/show_bug.cgi?id=2570 (not limited to these)

• Point of Contact: AntonShestakov (av6 on IRC)

• Potential mentors: Kevin Bullock (TheMystic on IRC), Pulkit Goyal (pulkitg on IRC)

5.3. Add terse option to status

Based on previous work by smf, add the ability to abbreviate the output of status by only listing the parent directory for multiple files.

Future work would be to improve the performance of hg status with this option by preventing Mercurial from descending into those directories at all.

5.3.1. Project properties

• Skills: Python

• Difficulty level: Easy / Intermediate

• Related reading/Links: https://www.mercurial-scm.org/pipermail/mercurial-devel/2015-October/074574.html

• Point of Contact: Sean Farley(smf on IRC), Augie Fackler(durin42 on IRC)

• Potential mentors: Kevin Bullock(TheMystic on IRC), Pulkit Goyal(pulkitg on IRC)

5.4. Release notes extension

Its based on release notes extension hacked up Gregory Szorc. This is about tagging commits with a release note area which can be used to produce release notes and can be integrated with existing commands to improve UX. Existing RST parser in use is designed to just parse help files - could limit to the common subset of RST that maps to wiki markup, and script that output. The project will be about polishing this extension so that it can be shipped with core and can help other organisations in producing release notes. Also adding features like linking hgweb to release notes, showing notes for commits you have pulled using hg pull and more.

5.4.1. Project properties

• Skills: Python

• Difficulty level: Easy / Intermediate

• Related reading/Links: Mailing list discussion Patch to mailing list Also contact Gregory about current state.

• Point of Contact: Gregory Szorc(indygreg on IRC), Augie Fackler(durin42 on IRC)

• Potential mentors: Augie Fackler (durin42 on IRC), Pulkit Goyal (pulkitg on IRC)

6. Other ideas?

Come talk to us on IRC.

CategoryGsoc