Canonical Voices

Posts tagged with 'why launchpad rocks'


This article is part of a series of articles about why I feel Launchpad is a great home for your Open Source project. I am writing these articles not as an employee of Canonical, but instead as a happy Launchpad user who gets agitated that not enough people know how cool Launchpad is.

Open Source is fundamentally driven by gifts. People contribute translations, documentation, artwork, code and more. Many of these gifts are made available in the form of patches; fragments of content that can be applied to other chunks of content to apply new features, resolve issues or add value in other ways. Patches are wonderful contributions. their authors take the time to care about a problem and invest their expertise and time in producing a solution that everyone can share and benefit from. As such, we should treat these patches with the due care and attention that they deserve.

Something we found in Ubuntu was that we were getting so many patches submitted that many were being lost in the mix and were not getting reviewed and applied if appropriate. This goes against the grain of a gift – we should always review these gifts with a strong sense of care and timeliness. The situation was not driven by carelessness or malice, but instead a lack of visibility on these available patches for a given project.

As such, we worked to build a new feature into Launchpad to provide a simple way of looking at all submitted patches. It looks like this:

Accessing this is simple; just add +patches to the end of a Launchpad project address. As an example for Zope

This also applies to source packages in Ubuntu. As an example for the Gwibber source package:

With each of these patch views you can order the patches by patch age, see the current status of the patch, and see it’s importance. This all provides a better way for these important contributions to be reviewed for the benefit of everyone.

See a list of all of these Why Launchpad Rocks articles here.

Read more

This article is part of a series of articles about why I feel Launchpad is a great home for your Open Source project. I am writing these articles not as an employee of Canonical, but instead as a happy Launchpad user who gets agitated that not enough people know how cool Launchpad is.

One of the things I love about Launchpad is that getting, hacking, sharing, merging in code is dead simple. Much of this is because of it’s tight integration with the Bazaar version control system. Together it provides a kid-in-candy-shop level of awesome if you like to run and hack on code.

One of the things I love about Bazaar is that it is focused on simplicity, and having used CVS and Subversion in the past, and a little bit of git recently, I find Bazaar by far the most naturally connected with my workflow. The reason for this is that I don’t want to care about version control. I am not interested in it, I don’t want to learn it, I don’t plan on sending it a Christmas card; I merely want to learn enough to get code from somewhere, upload it somewhere and rock with it. Bazaar is well suited to my needs because it’s simplicity means that it doesn’t feel like a pain to use.

Getting code is simple. I can click on the Code part of a Launchpad project and Launchpad tells me what command I need to run to grab a branch. As an example, if I want to download code from the Lernid project, I just run:

bzr branch lp:lernid

This gets me a branch easily, and I am ready to hack on it. when I have my feature or fix ready, I can then push it really easily with:

bzr push lp:~jonobacon/lernid/my-new-feature

…changing my-new-feature for whatever branch name I want to call it. At this point my branch will appear with the other branches in the Lernid project, so the other developers can download and try it. If I would like to ask the Lernid developers to merge it into their main trunk branch, I can Propose It For Merging in Launchpad which provides a user interface for the developers to review the branch, ask me comments, request changes and otherwise have a conversation about the proposed merge.

This all makes grabbing code, hacking on it, sharing it with others, and asking for it to be merged dead simple.

Not only this, but if you are interesting in contributing to Ubuntu, all source packages are held in Bazaar which means that the same tools and commands for working with code apply to working on one of the most popular Linux distributions too. You can read more about this here.

See a list of all of these Why Launchpad Rocks articles here.

Read more

This article is part of a series of articles about why I feel Launchpad is a great home for your Open Source project. I am writing these articles not as an employee of Canonical, but instead as a happy Launchpad user who gets agitated that not enough people know how cool Launchpad is.

Everyone has an opinion about bug trackers. I suspect my dad may even have an opinion, and I am pretty sure he has no idea what a bug tracker even is. The general consensus seems to be that everyone thinks that all bug trackers suck. A strong view, but one not entirely without merit given the fact that a vast majority of bug trackers do indeed suck. In the past I have mainly used Trac, SourceForge, Mantis and Bugzilla, and I have to say that I find Launchpad best suited to my needs and more importantly, most usable by my users who I expect to file a bug when something goes belly up.

I just want to zip through some of the reasons why I find bug tracking in Launchpad a breeze and well suited to all of my applications.


Of course, simplicity is a relative term, but I genuinely find that Launchpad provides the easiest interface for reporting bugs from the perspective of an end-user, and provides the easiest method of triaging and managing bugs. In terms of reporting bugs, the process is as simple as entering a subject and body content of the bug report. There are the usual additional options, but these are buried away a little so as not to confuse end-users. Launchpad also includes an excellent dupe-search to help end-users find existing bugs, yet still mark that it affects them without them having to engage in the irritating “me too” comment.

Ubuntu has been an excellent project for stress testing the triage and management of bugs, with literally thousands of bugs flowing through the system. The Launchpad team have reacted well to this feedback and now Launchpad feels like a nimble and efficient system for triage and management. The interface is simple and uncluttered and provides easy access to the different attributes of a bug report. Not only that but it is simple to query different classes of bug to make it simple to provide targeted work-lists for developers.

Bug Linking

One of the coolest features in Launchpad bug tracking is bug linking. Imagine the scenario that you work on a piece of upstream software that is shipped in three different distributions. The same bug could conceivably be filed against the main upstream project in Launchpad, as well as against the source packages for the project in each distributors bug tracker. This now means you have four different bugs that actually reflect the same bug, each with their own comment histories and possible patches.

The Launchpad team have produced a feature where you can link a bug in Launchpad with other bugs in Launchpad against different projects, and even link against bugs outside of Launchpad in Trac and Bugzilla. Launchpad can then pull the status and from these other bugs and reflect them in the main bug in Launchpad. This provides a way of consolidating these different bugs in one place which saves time and duplication of effort. The Launchpad team have produced a series of bug tracker plugins for Bugzilla and Trac which can share the comment history for the same bug tracked both in Launchpad and an external tracker. What’s more, to help find low-hanging fruit, there’s a “Bugs fixed elsewhere” report that shows which of your bugs are marked fixed in other communities.


Ultimately a bug conversation ideally leads to a fix. Launchpad has made it simple to bring bugs and fixes together. You can easily see any patches attached to a bug report and you can also jump straight to a list of all the bug reports, associated with your project, that have patches. This is ideal when new developers join your project; you can direct them at the list of outstanding unreviewed patches as a place to start.

For fixes that require more than a simple patch, you can link directly to the Bazaar branch (including imports from Git, Subversion and CVS) you’re working in, allowing everyone interested in the bug to watch your solution evolve or even download your branch, make their own changes and then upload them back to Launchpad for everyone to see. A single URL points to the latest version of the fix and a single command merges it into the project’s trunk branch.


Anyone who has been in the software business for a while will know that no matter how much you try to pre-empt the needs of developers, developers will always end up writing their own tools and workflow that suits them best. In other words, give the developer the tools to write their own tools and they will do incredible things. I think providing this kind of extensibility really demonstrates maturity in the creators of a software product. It shows that the tools provider is keen to help the developer get the very best solution, instead of being overly protective about building every possible solution in to their interface.

The Launchpad team have produced an API called launchpadlib that provides a RESTful Python API that lets you manipulate data in Launchpad just like any other Python object. In terms of bugs specifically, launchpadlib lets you report, access, and manage bugs, and also provides the ability to authenticate your apps to Launchpad. This means you can write tools to interface with your bugs that meet your specific needs, be it easier ways to triage, generate reports, or even embedding a modified bug submission form into your project’s website. A good example of this kind of third-party work is Bughugger; a desktop front-end to Launchpad bugs and Apport, a tool for reporting bugs in Ubuntu that automatically gathers debugging information.

See a list of all of these Why Launchpad Rocks articles here.

Read more

Today I want to start contributing to a solution for something that has been agitating me for a while. That is, simply not enough people know who wicked-cool Launchpad is.

I am what I would describe as an opportunistic programmer. I like to write programs in my spare time that are fun and interesting, and I like to share those programs with other people. I like to work together with other programmers to make these programs better so everyone who uses them benefits.

As such, I have tried a bunch of collaborative development websites. I tried SourceForge, I have used Trac, I tried setting up my own infrastructure, and ultimately I have always settled on Launchpad. The more I have used Launchpad the more I have discovered just how ideal it is for Open Source contributors to work together on software. Unfortunately, so many contributors have no idea of all this cool stuff that Launchpad can do. So, I am going to spurt a bunch of blog entries onto the Internet to help spread the word.

Now, let me be clear in my intentions and drive here. While I do work at Canonical, I don’t work on the Launchpad team. I am not responsible for building a Launchpad community. I am not responsible for telling people why you should use Launchpad, and the Launchpad team has not asked me to write these blog entries. Instead, I am writing these articles with my opportunistic developer hat on as opposed to my Canonical hat, and I hope you interpret these posts as such. :-)

I plan for these posts to mostly short and sweet and enough to get folks started in exploring a particular feature in Launchpad. I hope you like them.

Just Enough Goodness For My Project

One thing I love about Launchpad is that it gives me just enough of what I need for a software project. Back in the old days I used to use SourceForge to work on projects. It felt like a ten tonne hammer to crack a very small nut. I struggled along with it’s overly complex interface, filled with features I was never going to use. Like many developers, I found myself battling more with SourceForge than actually writing code for my programs.

So, I decided to give Trac a whirl. I loved it, and we used to hack on Jokosher in Trac for that very reason. While Trac was great for providing code-hosting, viewing and a built-in wiki, it’s issue tracker didn’t really meet our needs for a bug tracker. It also provided no answer tracking or translations features. As such we decided to move over to Launchpad and the project has been there ever since.

I feel Launchpad gets the right balance. It doesn’t overflow you with meaningless features that you will never use, but instead provides a well designed set of core tools that I have used for pretty much all of my projects. This includes:

  • Bug Tracking – a place to file bugs, triage them, attach fixes to them and manage them.
  • Code Hosting – a place to store and view your code and manage those branches.
  • Translations – a place where non-developers can contribute translations to your program.
  • Package Building – a place to build packages for Ubuntu and deliver them to users.
  • Specification Tracking – a place to plan features to be used in projects.
  • Community Support – a place where questions can be asked and answered.

My projects use all of these features and this is most of what I need in a development forge, with the only additional features that could be nice being a wiki and possibly a testing tracker. Not only does Launchpad give me enough of what I need to be productive, but it also integrates all of these components. As an example, branches in the code hosting component can be attached to bugs in the bug tracker.

See a list of all of these Why Launchpad Rocks articles here.

Read more