Posted on by Daniel Holbach

Field experiment: fix an Ubuntu bug

We want to make it easy to get involved in Ubuntu on a broad basis, but also make it easy to just go ahead and do something as a drive-by contribution.

At UDS we talked a lot about making it easy to just go and fix a bug that bothers you. We did a couple of improvements to our documentation and some other bits here and there.

What I now need is your feedback. It’d be super-sweet if you never just went and fixed a bug in Ubuntu, you now just tried to do that. I don’t want to give too many instructions, because I want to see how you go about finding docs, which tools you use, what you do to make it happen, so the instructions are thus:

  • Wear your hardhat.
  • Remember an Ubuntu bug that bothered you or find one you’d like to work on
  • Take notes. It’s important that you note down what exactly you tried to do, what worked and what didn’t work. We want to fix the process harder and make it super-smooth.
  • Add a comment to this blog entry or mail dholbach at ubuntu dot com with your findings.

Thanks a bunch in advance. This is an awesome opportunity for you to not only fix a bug in Ubuntu, but also help fix the process involved.

I’ll report the findings in a couple of weeks.

  • Stu

    I have tried to fix some Ubuntu bugs. I subscribed at Launchpad and make bug reports, send logs and send workarounds that make the problem go away on my system. As far as actually code goes, I am an old-fashioned programmer and have only contributed directly where the maintainer provided contact details and was receptive to contributed code or suggestions.

    That probably is not what you wanted to hear – but truly, I resist being funelled into some automaton colour-by-numbers route of bug-fixing for morons.

  • I filed two bug reports in Ubuntu. Both were triaged correctly within a reasonable time (couple of weeks) and fixes were posted for both. Only one fix was included in the distribution because the other is an “up stream” problem with compiz.

    The other became a paper cut briefly 6 months after I submitted it to papercuts… it was included in round 6 for the last release… then when round 6 of paper cuts came and went, it was removed from round 6 and not fixed.

    No public comment was ever made on the bug.

    When there is no guarantee that your code will be used, it’s hard to be motivated to fix something that requires a lot of your time. That’s why I think Stu says he only fixes bugs where he’s connected directly to the maintainer.

  • The first step to resolve a bug is to build the software from source. So the first question that comes to mind is: “who produces the software? who is the upstream?” This is not always clear. Once you’ve found that, you need to find out how to get the source and how to build it. Some packages are an absolute nightmare. Then once you’ve got past that hurdle, you have to dive into the code and understand it enough to debug it and fix the problem you have. Even when the software you’re investigating is written in a language you are familiar with, most mature packages are large enough that it may take you a good amount of time before you understand enough of it to be able to fix the problem you have.

    Then, once you’ve done all this, and assuming you manage to fix the problem on your machine, you need to contribute the patch and make sure it gets included. The procedure or doing so is not always clear and vary from one package to another.

    All this to say that the only piece of software for which I’ve managed to produce a patch so far is Shotwell, because the build process is simple, the code is well written and the Yorba guys are very responsive to queries.

    So in terms of how the process could work better, here are a few suggestions:
    * make it easy in Launchpad to find out who the upstream is,
    * talk to upstream to document the build process,
    * talk to upstream to document the patch submission process.

    All of this could be an extension of the Wiki page that describes how to forward a bug upstream: https://wiki.ubuntu.com/Bugs/Upstream

  • Bram Bonné

    I don’t know if you have already seen this blogpost. If you haven’t, the post (together with the comments) are probably an interesting read for you. It’s about improving Launchpad’s workflow for opportunistic programmers. And I just typed that last sentence so my comment looks less like a spam message 🙂

  • Robert

    This isn’t quite an answer to your question, but the first, and to this point only, bug I’ve spent significant time working on is #486154 . My comments trace my experience in trying to track down and fix the bug, so they should have some of the details you might be interested in. I’ll just make a few general comments here:
    1) Figuring out where the bug was was quite an adventure. The people who had made the changes we were trying to revert would not explain what had been changed, so I blamed packages more-or-less at random until I found the right one.
    2) There are no good tutorials on patching packages. The only ones I found were laughably simple (let’s change color to colour in the package description), described applying an existing patch, or were so advanced as to be useless to the novice. I eventually produced a patch, but I’m pretty sure I didn’t do it right.
    3) I still don’t know how to get the attention of the correct people to deal with a submitted patch. I posted the patch, requested a merge on Launchpad, submitted to upstream, and subscribed random groups, but the only review I got was one drive-by commenter who didn’t respond to my follow-up question.

    I’m sorry if I come off as overly negative, but this whole experience has been rather frustrating and has caused me to reconsider spending time on other bugs.

  • I think I’m the kind of user who could benefit of this experiment, I’ve never used any other distro bug track system before (although I’ve been playing with linux for at least 4 years) mainly because I’m a casual user and because they (the other bug track systems) looked over complicated for me, launchpad in the other hand is so simple that even I could make sense of it.

    I’ve just worked in the last week or so with 2 bugs (#519787 and #578129), the documentation is not really that bad (the howtofix article –https://wiki.ubuntu.com/Bugs/HowToFix– is the best reference in my own opinion for fast bug fixes) although some kind simple as someone has already pointed out, when I tried to work in the second patch (who was using quilt) I had to do it in my own, I read the debian documentation to have a random idea about it and how to use it.

    Making debdiffs didn’t look for me really difficult, now, what I’ve found frustrating is that in the first bug report someone told me I could make a merge but so far I’ve not been able to do it, the merge how to doesn’t make much sense for me. I haven’t asked in the #motu channel because I still don’t feel me really comfortable with my English level, I think it could be great if #motu could have some other international channels such as #motu-it, #motu-fr or #motu-es.

    I hadn’t noticed the Greg point, but that’s true, people wouldn’t like to spend a fair mount of their time finding out how to fix a bug in their own system later spending more hours figuring out how to make a debdiff and report it to finally see how their patch isn’t accepted/rejected or commented. I think the review team or whoever is making that work should get a lot more people.

    Thanks for trying to make ubuntu better 🙂 and excuse my poor English skills I just had to comment my experience.

  • Pingback: Renewed call for participation: fix an Ubuntu bug | Daniel Holbach’s blog()