Since the code for Launchpad was released as open source last summer we’ve had quite a few community members jump in and contribute significant changes. We have a list of contributions that is automatically updated every ten minutes to show the top contributors and their branches.
There is a core team of about 25 people who work on Launchpad and we’ve developed a pretty good process for managing our development. We have some effective tools (including many new features to Launchpad itself), processes, and guidelines to make our work as efficient as possible. We continually strive to improve, so the way we do things today are different than what we did three or six months ago. Some times new tools (such as merge proposals) cause a huge (hopefully positive) change in our process. Other changes are small refinements.
That said, let’s talk about the current process for contributing code to Launchpad.
The steps for fixing a bug or adding a new feature in Launchpad are:
- Find a bug or feature request. The best place to look is on the milestone for the application of interest. (See the list for Launchpad Registry’s 10.02 milestone).
- Research the problem.
- Have a pre-implemention call.
- Grab the latest branch of Launchpad (which we informally call ‘rocketfuel’). You can use ‘rocketfuel-get’ to update your copy of devel and ‘rocketfuel-branch’ to make a branch for your work. It’s best to create a new branch for each chunk of work you do.
- Write your tests, write the code, repeat. (Read about TDD.)
- Push your code to Launchpad (‘bzr push’).
- Create a merge proposal (‘bzr send’).
- Have a review, fix changes, repeat.
- Run the tests. At a minimum you should run all the tests for the application you changed. For bugs you can do that with ‘bin/test -vvm lp.bugs’.
- Submit to PQM.
- QA the change when it lands on edge or staging.
- See the change in production when the next release rolls out.
- Bask in your awesomeness.
As a community contributor it is imperative that you have a pre-implementation call before you start work. The purpose it so ensure the bug fix or feature is desired right now and to vet your proposed solution. The call needs to be with a Launchpad developer who is an expert on the application you’ll be changing. So don’t have a pre-imp call with a translations guy if you intend to fix a bug in Soyuz!
One practice we are devoted to is that of peer code reviews, as listed above. Every branch must go through the code review process before being merged. While the process is expensive in terms of time and resources we believe the benefits are substantial. The obvious advantage is the chance to catch errors before they appear in production. Correcting mistakes becomes harder and more expensive the later in the development cycle that they are discovered, so catching errors before committing them to the trunk is key. The other benefit is the knowledge transfer that occurs when a reviewer reads someone else’s code. It is an opportunity for cross-platform training and sharing of techniques in both directions. The review is a conversation, not a confrontation, so it should be a rewarding and enjoyable experience with the end goal of improving the code at hand and the skills of both parties.
Every workday we have reviewers on call in #launchpad-reviews for the singular purpose of providing real-time, interactive reviews. If you show up there an ask for a review you can probably get it done within a couple of hours. Alternatively, the act of sending in your merge proposal will queue up your request on +activereviews and it will eventually get reviewed. But remember it is your responsibility to move your branch along so don’t be shy about asking for a review.
Finally, when your merge proposal is approved you’re ready to have your branch merged. We only merge branches after they have passed all of the tests in our test suite. The easiest way to do that is by running them on Amazon’s ec2 cloud. Our tools for doing that will automatically send a request to PQM if the tests pass. Access to PQM is limited to Canonical employees so you’ll need to have a Canonical Launchpad developer run your tests and land your branch. An added advantage to you is we get stuck with the bill from Amazon for ec2, not you! Luckily the history tracked by Bazaar will identify you as the contributor so you’ll get full credit for the fix even though it is landed by someone else. Before you ask for your branch to be committed be sure to set the commit message on your merge proposal. The message briefly identifies your branch and is logged by PQM.
Thanks for your interest in improving Launchpad. If you have questions please ask on #launchpad-dev or contact me at bac (at) canonical.com.