Improving Launchpad bug workflow for opportunistic programmers
Canonical
on 24 January 2010
Tags: Design , programming , Ubuntu
I’m a talented software engineer. I have a good deal of application programming experience on Windows, Mac OS, Linux, iPhone, Android, and the Web. I’m crazy about style guidelines, correctness, functional decomposition, self-documenting code, explicit documentation, code review, unit tests, etc. I’m confident that for most application codebases, I could learn my way around quickly enough to make meaningful bug fixes and other improvements.
Despite being good at these things, the barrier to entry for fixing a bug in any given application (paper cuts are a very good example of the kind of bug I’d like to fix) is still very high for me. I am lousy at chasing down dependencies, maintaining clean build environments, generating patches, and dealing with unfamiliar version control systems. I know next to nothing about packaging or publishing PPAs. Some of you may read this and think, “well, that’s your fault–stop complaining and learn these things,” but I contend that there are very many talented, opportunistic programmers just waiting to contribute by doing what they do best–writing code. These eager programmers are similarly hindered by this barrier to entry, and we would benefit more by accommodating them than by insisting that they accommodate us. Furthermore, we have the ability to completely automate the stuff that isn’t software development and hide its complexity from developers–in fact, we’re already mostly there. To illustrate my point, I present my ideal user story for fixing a paper cut.
I want to fix bug #511767, “‘Hash for Duplicates’” is tech-speak.” F-Spot has a great feature for finding duplicate images in your photo library and getting rid of unwanted copies; however, this useful feature is exposed to the user under the label “Hash for Duplicates.” The user likely doesn’t know what hashing is. Besides, the user wants to find duplicates, not hash them–hashing is just an implementation detail. To fix this bug, I click “Quickly fix this bug,” right on the bug report in Launchpad:
Automagically, an application on my machine opens to handle the URL behind the Quickly fix link (e.g. lp://fix/?bug=511767). This application performs the following steps on my behalf:
- Runs
apt-get build-dep f-spot
to prepare my machine to build the package affected by the bug. - Runs
apt-get source f-spot
to download a source package that can be built on my machine. - Opens the f-spot source in Eclipse*, where the source package is built for me.
- …and presumably cleans up the mess after I’m done.
* Why Eclipse and not [insert your favorite IDE/editor here]? Because Eclipse is extensible, popular, cross-platform, and supports many different languages, but most of all, I picked Eclipse hoping we could just skip the endless debate where everyone argues that we should use the IDE they wrote “Hello, World” in once.
With the exception of typing my password if needed, the next thing I should see after clicking “Quickly fix this bug” is the F-Spot source package open and built in Eclipse, where I can “quickly fix” the bug:
With one click, Eclipse builds and runs the project to let me test my changes:
Looks good to me! Time to submit my changes to the Launchpad bug report. With one additional click, Eclipse can push my changes to a PPA, publish a Bazaar branch and generate a merge proposal, or simply attach the patch to the Launchpad bug report. I choose “Attach Patch to Bug Report,” so Eclipse creates a patch, opens my browser to the patch submission form on the Launchpad bug report, attaches the patch, and leaves it to me to add a comment and submit:
To summarize, this user story consists of the following steps to create, test, and submit a patch for a small bug:
- Click “Quickly fix this bug” on the Launchpad bug report.
- Edit the source of the corresponding package in Eclipse.
- Build the project and test the changes.
- Submit the patch and comment back to Launchpad.
Which version control software does upstream use for this package? How do I get the code? Which build environment or IDE do they recommend? What dependencies does the package have? How do I use debuild? I shouldn’t have to know the answers to any of these questions to fix the bug in question. Can we make this quantum leap forward in our bug workflow? Even if we were to enable “Quickly fix this bug” for only a handful of important packages, this would be a tremendous force in improving the quality of software in Ubuntu.
Talk to us today
Interested in running Ubuntu in your organisation?
Newsletter signup
Related posts
Visual Testing: GitHub Actions Migration & Test Optimisation
What is Visual Testing? Visual testing analyses the visual appearance of a user interface. Snapshots of pages are taken to create a “baseline”, or the current...
Maximizing CPU efficiency and energy savings with IntelⓇ QuickAssist Technology on Ubuntu 24.04
In this post, we show that IntelⓇ QAT can be used in Ubuntu 24.04 LTS to offload compute intensive workloads, maximizing CPU efficiency and driving cost savings.
Meet Canonical at SIGGRAPH 2024: Innovating Animation and VFX
We are coming to Siggraph 2024. Discover how Ubuntu and other Canonical solutions can drive innovation in animation and enable secure usage of open-source software.