sil2100//vx developer log

Welcome to my personal web page

Contributing to Ubuntu on Launchpad

It's really really busy on my side lately, especially since I got assigned to take care of some of release integration. That's why this time I'd like to write a bit less-technical post. I would like to share my experiences related to contributing to some of the official Ubuntu projects hosted on Launchpad. Ubuntu being first of all an open source community based system, most of its development happens due to contributions. It's really easy getting started! This might be considered as a pseudo-tutorial combined with a bit of soap-opera.

2012-06-28 19:48

As most of you know, almost all Ubuntu related development happens on Launchpad. In combination with bazaar (bzr), Launchpad provides a very useful interface for submitting user contributions to any hosted code. Even though I'm more of a git fan, bazaar is rather OK for fix contributing. Although some things got me irritated at first. Most projects accept contributions on a merge-request-and-review basis. Just find the LP page of a project you are interested in, target appropriate bug, assign to yourself, create bzr branch, request merge and wait for reviews. It's actually much easier than it sounds.

My first, real contributions since I started working for Canonical resolved around the compiz, Unity and Unity 2D projects. Because of their importance to the user experience, there is actually quite a lot people involved in their development - so it's rather easy to start. The first thing I had to do is getting in touch with people responsible for the management of these projects. Entering the actual community of a given project can be very helpful, as other developers can provide insight and advice regarding troublesome issues in the given project.
The best channel for communication: IRC. Most contributors have time-zone information given, along with the IRC nickname used and IRC server (although Freenode is probably where you should look first). This way we can identify people we want to poke for more information or advice and when to do it. If no maintainers are available on IRC, fall-back to e-mail.

I had some bugs in need of fixing. I assigned them to me and started my work. Usually it is wise to ask the existing maintainers and developers about the planned fix before actually preparing it. It's good to use the experience of others - and it also saves some time on rewriting the fix after getting rejected. And probably prepare yourself for getting rejected or having to modify your code A LOT - since this happens very frequently.
I remember having some problem with the lack of documentation for compiz. There are many projects like this sadly. In this case, the best way is just asking others for information if the source code itself is not enough. It's good to remember that asking is nothing shameful.

Then, after preparing the fix, comes the time for submitting a merge request. First of all, we clone the initial project's bzr branch and commit our fix to that branch. We then push it to launchpad, to our own branch. Usually it's best to push it to lp:~launchpadid/project/name_of_the_branch, there: launchpadid is your LP name, project is the name of the project we're submitting the fix to (e.g. compiz) and name_of_the_branch is any more-or-less informative and fitting name for our fix.
After this is done, we can go into that branch and request a merge through the web interface. When requesting a merge, we are asked to provide the description of the fix and other information, if needed. We need to remember that, for Ubuntu projects, writing a description and also a commit message is mandatory. And it's best if we follow the following structure when writing the description:

 - Problem description
 [Input here the detailed description of the problem being fixed]

 - Fix description
 [Describe here how the code you are submitting fixes the problem]

 - Test coverage
 [How to test that the fix is correct? How are you ensuring it's fixed?]

After submitting a merge request, we wait until someone (a maintainer or other developer) performs a review of your code. If it gets approved, someone will begin the process of merging it into trunk sooner or later - usually sooner. How this is done varies from project to project - some bigger Ubuntu projects, like Unity, have it done automatically through a bot (or e.g. jenkins) but some others need the maintainer to merge the change manually.

It's really satisfying when you see your first fix getting merged upstream. I remember I was very happy when my merge request finally made it upstream. When you're new to the code, it can be hard to fit into the code-style too. But usually, after our fix is merged, project maintainers or bug supervisors will take care of closing the bug and preparing it as needed, so here ends our work.
Sometimes some maintainers might ask us to resubmit the same fix for an older branch, especially if the fix is important and fits the SRU profile (Stable Release Update - read more about it here). But this is usually trivial to do - usually just a bzr merge -c revnum to cherry-pick from your branch to the new one.

As you can see, the process of contributing to Ubuntu projects is very simple and fast. Some small advice to remember:

That being said, I have really good memories of my first contributions to Ubuntu. Since the current stable version, the 12.04 Precise Pangolin, is a LTS (Long Term Support) version, contributing as much fixes as possible is crucial. Because this release is supposed to be stable and precise for a long period of time, I encourage everyone to try his strength in making Ubuntu rock-solid and rock-hard. For beginners, I would recommend looking at Unity-2D and probably Unity, but there are also many many more upstream Ubuntu projects needing attention.

Hope to see you on Launchpad, soon! I might even the one to review your code..!