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.
Simplicity
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.
Fixes
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.
Extensibility
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.
