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-spotto prepare my machine to build the package affected by the bug. - Runs
apt-get source f-spotto 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.
26 comments
+1!
Sad to see you’re encouraging users to not submit patches upstream!
Very cool idea. Would be interesting to see an implementation. But, I think the most difficult part for a lot of these bugs is figuring out where they occur. Things like strings are stupidly hidden in most applications.
@Luis Medinas, for Ubuntu in LP the bugs can be linked upstream. So if someone posted the patch there it’d automatically be sent upstream if the upstream bug tracker allowed it. And, FWIW, Launchpad *is* upstream for many projects.
You make it sound so simple =D
Neat idea, especially if it was implemented in such a way that (as Luis implies), upstream (and other distro) bugzillas could hook into it directly, and that distros could provide their own package manager backends.
I could bikeshed the IDE choice (it does say “Quickly” Fix, after all), but more seriously, since proper IDE-specifc projects can be a pain to produce, I don’t think it would be a big hurdle to include “install the recommended IDE” in the Quickly Fix process.
How do you forsee the “run modified app” part of this working? Installing in a private prefix, or through a `make run` target?
Another good idea might be to set XDG* env vars when running the modified app so that you aren’t messing with your real data.
Do you think app-specific modifications of these steps should be specified in Launchpad, for example, or in some standard file at the root of the source checkout?
I wouldn’t say I’m a talented software engineer (yet) but I certainly agree with you that instead of telling developers to _learn_ how to build software from source, including how to learn different version control systems like git/cvs/bzr/svn/etc. and to make changes that these difficulties should be taken care of by Launchpad/Eclipse (or editor of their choice).
This is the major roadblock to for me to submitting bug fixes and patches and hense even when I’m all signed up and ready to go with helping the GetDeb.net interface, I find myself having to jump through hoops just to see the changes that were made since I last downloaded the code, then having to edit the code (using … in this case bzr) and then thirdly having to upload the code, making sure my files are in proper order, that I have a commit comment and then if there is a conflict with another developer, then I might give up if I just really don’t have the time.
There’s too much in the way for a potential developer to help any projects and it takes too much commitment, so many just say “no thanks” or “some one else will fix it.”
Of course, that being said, we need at least one person in every project to have control over all the commits to make sure the quality of each release is there, but lowering the barrier to fix bugs has nothing but potential.
So +1 from me.
Ted, the application in the example is f-spot and it uses the gnome bugzilla it would be much better to indicate people to submit patches there so everyone could see. Also it improves QA and upstream get’s notified about it.
It wouldn’t be the first time gnome developers don’t get notified about patches on ubuntu
You should probably think of using a web-only approach. Checking out the projects sources onto a web editor and building on some server seems right here.
@Christoph you then lose the ability to test it on your local machine.
Fantastic idea, David.
It seems that Ubuntu thinks that upstream’s job is to find patches which have been applied to the various distros.
No. But you’re right, Ubuntu doesn’t think ‘a priori’ that it needs to push everything it does upstream.
This “upstream before all else” is almost a disease. The whole point of open source software is supposed to be that you can change it and customize it to create the best system you need — and that includes a company creating a product. NOT making everyone use the exact same patch set.
Ubuntu should decide how to customize the Linux product that it produces, and push upstream changes as it sees fit – and upstream may grab anything that it likes in Ubuntu (as these patches are often public).
Only thing I see here is a fallacy that downstreams should do upstream’s QA job for them.
Keep them aware of the bugs, and provide them access to the work you do. But as a user of any distribution, you are not required to contribute directly to upstream – and in many cases it’s counterproductive. Ubuntu already diverges with upstream in many software packages anyway.
Upstream cooperation is an issue, correct! This is not the right solution in and on itself.
On the other hand, I think it might be beneficial and support adoption and happiness with the developers if you would always show the user coding guidelines (or the general readme, stuff like that).
Damn you! I thought this feature was already implemented!
You and your nearly realistic mockups ;p
Great idea, David! I would love to see something like this implemented. Even if you ignore the burden to learn the required tools to fix a bug, it saves a ton of time in having to deal with all of the work necessary to get the source up and running. I would love to see this implemented.
I agree with your plight of potential developers willing to fix things on the opensource projects but aren’t.
If the initial hassle of setting up things and automating the build environment itself could motivate a lot of people to improve the quality of code.
I would like to have a system in terms of,
- gets/checks out the code
- have tools/utilities to build on a “sandbox” setup (say private –prefix)
- Run the application without spoiling the existing setup.
- Prepares submit patch to the upstream system.
This will leave to focusing on hunting the bug and fixing it, without the hassle of making sure it does not spoils my “everyday” system.
I promise you I’ll fix atleast 1 bug every week if you have this implemented.. Fantastic idea!
This is an INCREDIBLE feature! I’m going to use this all the time!
Bravo!
That would be a really useful feature. For me, the part about packaging the fixed code and uploading it to PPA for users to test is the most complicated part (I always have to sift through the useful but long Ubuntu Help pages to find the right dch/debuild/dput commands).
Btw. maybe this feature could even be integrated into applications itself: similar to Help -> Report a Problem in this Application there could be a “Modify this Application”, inviting users to toy around with the code for an app.
Hey David,
Great idea. Karl Fogel went through almost exactly this story at the last Launchpad team meeting. We might well have even written it up somewhere on http://dev.launchpad.net
Anyway, this is exactly the kind of story we’re working on right now on Launchpad.
Keep the dream alive!
jml
I’ve tried mucking around before, and I agree, getting everything working is a big hassle.
If you manage to get this thing working on Launchpad, it would be a great help.
Great idea.
Hopefully people can comment on the idea rather than start an Ubuntu-upstream debate again
In the past I worked on something similar: http://github.com/jewel/apt-hack
Once apt-hack is installed, your workflow is:
apt-hack fork f-spot
cd ~/src/f-spot
gedit src/…
apt-hack build
apt-hack install
It’s not perfect by any means, and my goals were a little different, but the premise is the same.
@Luis I encourage no such thing. Furthermore, Ubuntu is catagorically in favor of pushing any patches submitted to Launchpad upstream.
@Sandy Yeah, we might need to use a VM. Maybe have a root VM image that gets forked and preped to build each package. “Quickly fixing” a bug in a package like Nautilus could make testing tricky.
@Christoph That sounds insane! I bet that would require a lot more work, though.
@Bruce *No, only patches the Ubuntu community is producing and posting to Launchpad. We’re writing patches, applying them to our distro, and creating a system to share them with the original authors… What should we do differently? Not write the patches? Not send them upstream?
@twilightomni If Ubuntu doesn’t produce patches, it makes enemies. When it does produce patches, it’s accused of hording them/forcing them upstream. I don’t think we can convince everyone that we’re just trying to improve free software and share those improvements with everyone…
@Jonathan, awesome! Good to hear.
@Jewel, awesome! I love it.
Hi David, nice user story.
I’m an eclipse plugin developer and your use case is “almost” what I’m doing every day.
Did you hear about Mylyn (http://www.eclipse.org/mylyn/) ?
Basically it let you manage your issues/bugs/tasks within eclipse, and creates a context with every modified resources during the time working on the bug. This context is automatically attached to the bug when you close it. It is also integrated with VCS and automatically creates a commit message.
Maybe all you need is a Mylyn Connector for Launchpad.
My 2 cents.
Amazing idea.
I like the idea.
And your browser could have a little button that’s a count box of quick fix bugs so that you feel motivated to bring down the total count.
But by the time anyone’s triaged a bug enough to figure out if it’s quick to fix and could go in this category, they might have a hard time not just fixing it then and there.