In my travels around Launchpad looking for bugs to triage, I came across an old one that I noticed (but not before others apparently) in the Alpha 1 release of Oneiric Ocelot. This was a problem with update-manager not ‘seeing’ that network-manager had a connection because the new version of network-manager (0.9) uses different codes to express ‘connected’.

This issue was bugging me, so I decided I’d take it upon myself to patch it up. Someone had done a similar patch in software-center so I already had all of the knowledge needed right there (i.e. what are the new codes). I jumped into my Oneiric VM, branched the update-manager code and hacked away at a couple of Python modules, tweaked, buffed and polished until lo and behold, on starting update-manager it picked up the connection! A few command lines (bzr stat, bzr commit, bzr push) and a few clicks in Launchpad later my merge request was with the update-manager project maintainer (Michael Vogt aka mvo). Minutes later it was merged and the next day with the help of my patched version of update-manager I was able to update update-manager with the patch.

Looking at my own name there in update-manager’s description of the change, I couldn’t help but think how awesome it is that I’m able to do this with my favourite operating system. That’s what makes OSS magic for me…

When I worked in the Symbian Foundation, as part of the (Symbian) Bug Squad activities that I helped run we would (try) to have regular get together on IRC where the community would come together and work on something in particular. Mainly this was getting triaging done. We didn’t have the benefit of a lot of experience, so this would be done in something of an ad-hoc way with everyone discussing each bugs status and priority until we reached a conclusion.

Now that I’m at Canonical and trying to participate heavily in Ubuntu’s Bug Squad activities, it’s comforting to know that something similar goes on here (maybe we were subconsciously influenced by it ?). It also happens to be on the same day (Thursday) of the week. I’m of course referring to Hug Days, which are co-ordinated by the QA team. I’ve been involved in them over the last few weeks as a participant (rather than an organiser) and I find the structure to be very good and very accessible. Quite simply there is a list of bugs with different statuses (New, Confirmed or Incomplete) and simple instructions on what to do with each bug. New bugs need to be either Confirmed or set to Incomplete if you find you need to ask the reporter for extra details to be able to reproduce the bug. Confirmed bugs themselves need to be revisited and a check done to make sure the bug is still happening, leading to the bug either being Triaged or set back to Incomplete if it’s not happening and you need the reporter to reconfirm. Lastly, Incomplete bugs should be checked for a response from the reporter to the information request. If they gave the necessary info then the bug should be Confirmed. If not a follow up question should be asked and the bug left as Incomplete.

Some tools that are handy to have to assist with the process of going through all these bug reports and updating them correctly are the Hug Day tools, which semi-automate the process of ‘closing’ Hug Day bugs (they aren’t being closed as bugs, but as tasks on the Hug Day), as well as the Firefox Launchpad Improvements, which are useful not just for Hug Days but any bug work. The improvements include canned bug comments for common scenarios such as when an inexperienced bug filer has provided little info on the bug and you need to tell them to provide simple steps to reproduce the bug.

Each Hug Day is based on a particular package (which helps to focus the effort) and this weeks Hug Day is on Nautilus, Ubuntu’s file browser. I have and will be participating in this as much as I can, so if you decide to participate in it then say Hi on Freenode IRC #ubuntu-bugs where there are lots of knowledgeable Ubuntu people waiting to help out newcomers with the task at hand. See you there!

Apport has provided built-in support for automatically identifying and marking duplicate bug reports for normal signal as well as Python crashes. However, we have more kinds of bug reports submitted through Apport which could benefit from automatic duplication: X.org GPU freezes, package installation failures, kernel oopses, or gcc internal compiler errors, i. e. pretty much everything that gets reported automatically these days.

The latest Apport 1.20 (which also just hit current Ubuntu Natty) now allows package hooks to set a special field DuplicateSignature, which abstracts the concept for other kinds of bug reports where Apport doesn’t do automatic duplication. This field should both uniquely identify the problem class (e. g. “XorgGPUFreeze”) as well as the particular problem, i. e. variables which tell this instance apart from different problems. Aside from these requirements, the value can be any free-form string, Apport only treats it as an opaque value. It doesn’t even need to be ASCII only or only be one line, but for better human inspection I recommend this.

So your report could do something like

   report['DuplicateSignature'] = 'XorgGPUFreeze: instruction %s regs:%s:%s:%s' % (
                     current_instruction, regs[0], regs[1], regs[2])

or

    report['DuplicateSignature'] = 'PackageFailure: ' + log.splitlines()[-1]

This is integrated into Apport’s already existing CrashDatabase class, which maintains a signature ?master bug mapping in a SQLite database. So far these contained the crash signatures (built from executable name, signal number, and the topmost 5 stack trace names). As usual, if an incoming report defines a duplicate signature (from the crash stack trace or from DuplicateSignature), the first one will become the master bug, and all subsequent reports will automatically get closed as a duplicate in Launchpad.

Thanks to Bryce Harrington, who already came up with using this in the latest Intel X.org graphics driver for GPU hangs!

Short story: http://pad.lv/12345 takes you to bug 12345, and pad.lv describes more abbreviations.

Sometimes you’d like to point people to an interesting bug in a project that uses Launchpad, like bug 685380 (that ‘1′ and ‘l’ may need to be more distinct in the new Ubuntu Font).

Typing out https://launchpad.net/bugs/685380 is a bit tedious, and it uses up a fair bit of space in a microblog entry. You can use any of innumerable URL-shortening services, but then the URL’s opaque; which is a shame since it really just wants to represent a 6-digit number.

Therefore: pad.lv (pad love), transparent short URLs for bugs, and other things including projects, people, bug-filing forms, packages, and more.

Maybe someone would like to make bookmarklets that generate these links, or add them into the Launchpad UI?

Thanks to Latvia for letting us use a fraction of their domain name space!

Hi Folks,
It is that time again. Time for our regularly scheduled Bug Day [0]. Like last time we will be focusing on the bugs in the new state. We had a great amount of work done last time, and I’d like for us to keep that momentum going. There are a number of these bugs that have been improperly set to New when they should be either Triaged or Confirmed. My goal is for us to get as many of them properly set as possible. Additionally, we’d like to perform our basic triage on the ones that are, in fact, new. This includes a brief review of the information that has been provided and a request for what is missing so that we can get as many as possible into the triaged state for further review by the team.
I’d like to take a moment and thank those people on the team for working on the bugs with patches that we have. Through their efforts the number is the lowest it has been since I started here. There has also been quite a bit of effort put into continual review of the regression-proposed bugs. We now have them in a good place. All of this is due to the extra effort the team has put in, in addition to the massive amounts of work they normally do to achieve this. Thanks guys for your efforts.

Parties interested in beginning triage or if you have questions about what to do, or if you just find yourself stuck on a bug and are not certain how to continue, please reach out to me in the #ubuntu-kernel channel on FreeNode. I’m always there, and I am always willing to help.

[0] https://wiki.ubuntu.com/Kernel/BugTriage/BugDay

As part of improving performance we have disabled the substring matching of source package names. This fixes bug 268508 and bug 607960. However its a slightly contentious issue – opinions vary about whether bug 268508 is a valid bug or not.

So we have only disabled it – the code is still present and when we have more leeway on the performance of bug searching we’ll revisit this and look into some design and UI analysis to decide whether substring matching of this sort should be done or not.

For now though, there should be less timeouts in bug searches.

As we foreshadowed last October, bug expiry is now active again.

Bugs that are marked Incomplete and that haven’t been touched for 60 days will now start moving to the Expired state. If it turns out the bug’s still useful or valid, anyone can move it back.

We recommend people use the Incomplete state to mean: if this bug report doesn’t get more information, there’s nothing we can do with it.

This only affects projects expire incomplete bug reports setting turned on in the Configure bug tracker page.

As many of you have experienced this week, I have begun a (somewhat) aggressive review of old bugs for the Kernel package. In some cases bugs are being marked Invalid or Won’t Fix, and I am sure some of you will take issue with that. I’d like to explain some of the rationale behind these decisions and, hopefully, allay the majority of your fears concerning these issues.

First, I am not attempting to lessen the difficulty of any of these reported issues. I am marking the majority of the bugs Invalid due to the overwhelming responses of reporters having ‘similar’ issues. This has resulted in a watering down of the issue as reported by the Original Reporter. I do not wish to convey the notion that those of you encountering those issues are not important, quite the opposite. I am simply wishing to close an issue that is not really able to be solved and asking those of you experiencing issues of a similar nature in unique bugs of your own. This empowers me as a triager to drill down to individual causes of your issue and get that information in front of the team as opposed to trying to understand a variety of, possibly unrelated, issues from a multitude of reporters.

In some cases, you will see the Invalid status being applied to bugs that are very old. In these cases my preference is for affected users to, again, submit me a new bug with all of the relevant information. This gives me all of the benefits I have outlined above in addition to giving us brand new evidence of an issue in the current development release and will give the team a chance to take a fresh look at a longstanding issue.

There are also those bugs that have been Fix Released at some point in the past due to updates to a kernel. Well meaning reporters who experience a seemingly similar issue have, in the past, reopened these under an incorrect status and they have been lost in the shuffle of thousands of other issues. Let me say right now that it is not our policy to reopen Fixed bugs and I consider it a major no-no. To those of you I fuss at for doing this, I apologize in advance.

Some of you will have seen bugs that are set to Won’t Fix. These are issues that are (once again, in most cases) being defined as hardware faults, BIOS issues or unrelated software configuration problems and cannot be fixed by changes in the kernel. In these cases, they are being marked Won’t Fix not our of a desire to keep from actually fixing an issue but in an effort to allow those invested in a product to take the opportunity to solve the problem in the correct location.

I speak from an experience around the team when I say that we would love to solve all of the issues presented to us. The reality is that we are able to take time on very few reported issues directly. The vast majority of fixes come through upstream commits or via new drivers provided by third parties.

To those of you who get annoyed when it seems that all I ever say on a bug is, “Is this still a problem in ” all I can do is shrug. Given the avenues open to us whereby a possible fix could come, I can only ask in that way. Please understand, I’d prefer there were some easier way. Thanks for your patience as the team and I work to make this one of the easiest to use distributions while supporting the most hardware possible.

Finally, I’d like to say that, with such a broad install base and with such a large number of legacy devices available in the wild, there will be some cases where our answer to whether we will be able to support your specific device may end up being “No”. Please forgive me in those instances when I must be the bearer of bad news.

Thank you to all of you who help to triage bugs, update wiki pages and attend learning events put out by the Community team. With all of your help we can continue to improve our chosen operating system and make it more useful to those who would be free.

~JFo

Hi everyone!

It is time once again to hold a Kernel Bug Day. I will start blogging these events now instead of only sending out the usual e-mail. I hope that some of you will join in.

This Tuesday, December 7th, the Kernel team will conduct a Bug Day focused on bugs tagged ‘regression-update’. These bugs are an indication that some update to the kernel caused a failure. We’d like for these bugs to be brought current by requesting testing on one of the other versions to include mainline and current development. Your help in requesting that information and in completing the general triage of these bugs would be greatly appreciated.

Information concerning the Bug Day itself can be located on the wiki at https://wiki.ubuntu.com/Kernel/BugTriage/BugDay. As noted there and in the e-mail I sent out earlier, should you desire a head start on the triage day, that contribution too is most appreciated.

I will be available in the #ubuntu-kernel channel of the FreeNode IRC server should you have any questions.

Happy Triaging!

~JFo

The Debian import freeze is settled, the first rush of major changes went into Maverick, and the dust now has settled a bit. Thus it’s time to turn back some attention to crashes and quality in general.

This morning I created maverick chroots for the Apport retracers, and they are currently processing the backlog. I also uploaded a new Apport package which now enables crash reporting by default again.

Happy segfaulting!

This is just a quick note really. One thing I've been trying to do more and more is to address simple bugs in a more timely manner.

I use the tag "trivial" to indicate to me that the bug is very simple to fix. By this I mean that I should be able to have the fix and the test all written in under an hour, and normally under 30 minutes.

Personally I'm (hopefully) fixing one trivial bug a day in addition to other work. This way the simple bugs get some attention, and I get the feeling of accomplishing something when other things are in the pipeline that take longer to get completed.

My scheduling of trivial bugs is somewhat arbitrary. Often the most recently commented on trivial bug will get my attention.

Thanks to the work of David Henningsson, we now have a proper Apport symptom for audio bugs. It just got updated again to set default bug titles, which include the card/codec name and the problem, so that Launchpad’s suggested duplicates should work much more reliably.

So from now on you are strongly encouraged to report sound problems with

$ ubuntu-bug audio

instead of trying to guess the package right.

I finally listened to Sebastien Bacher and applied for GNOME commit rights yesterday, after hassling Seb once more about committing an approved patch for me. Surprisingly, it only took some 4 hours until my application was approved and my account created, wow! Apparently 71 patches are enough.

With my new powers, I fixed a crash in gdm, and applied two stragglers into gvfs’ build system today.

More to come!

The days before Chistmas are a wonderfully quiet time to catch up on old work which otherwise just drowns in the daily noise. I got a lot of Apport cleanups and improvements done.

One particular highlight of 1.11 is that it is now easy and consistent to collect information for a bug report on one place/at one time and save it into a file

$ apport-bug --save /tmp/argh.apport udev

… and report that later on with

$ apport-bug /tmp/argh.apport

This can happen on an entirely different machine.

Hi all,

Here’s just a reminder that we’re having a bug squash fest on Ubuntu Translations bugs today, so get your spray cans ready and join us at #ubuntu-bugs for the Hug Day!:

Announcing the Next Ubuntu Bug Day! - Thursday 03 December 2009

Fellow Ubuntu Triagers!

This week's Bug Day target is *drum roll please* Ubuntu Translations!
 * 7 New bugs need a hug
 * 14 Incomplete bugs need a status check
 * 71 Confirmed bugs need a review

Bookmark it, add it to your calendars, turn over those egg-timers!
 * Thursday 03 December 2009
 * https://wiki.ubuntu.com/UbuntuBugDay/20091203

Are you looking for a way to start giving some love back to your
adorable Ubuntu Project?
Did you ever wonder what Triage is? Want to learn about that?
This is a perfect time!, Everybody can help in a Bug Day!
open your IRC Client and go to #ubuntu-bugs (FreeNode)
the BugSquad will be happy to help you to start contributing!

Wanna be famous? Is easy! remember to use 5-A-day so if you do a good
work your name could be listed at the top 5-A-Day Contributors in the
Ubuntu Hall of Fame page!

We are always looking for new tasks or ideas for the Bug Days, if you have one
add it to the Planning page https://wiki.ubuntu.com/UbuntuBugDay/Planning

If you're new to all this (like me), head to
 http://wiki.ubuntu.com/Bugs

Original announcement

How can you help with translations bugs?

Remember that you don’t have to wait for a Hug Day to help with Ubuntu Translations bugs, you can contribute any day!

Here are a couple of things you can give a hand with:

• Reporting translations bugs
• Triaging the existing bugs at the Ubuntu Translations project in Launchpad
• Subscribing to Ubuntu Translations bugmail

Translations Meeting

Today is a busy day in translations world, as we’re having our monthly meeting as well:

• WHAT: Ubuntu Translations monthly meeting (Agenda)
• WHERE: #ubuntu-meeting IRC channel on Freenode
• WHEN: Thursday, 3rd Dec 2009, 15.00 UTC

Come and join us for any of these events and let’s make native language support in Ubuntu rock.

Image: http://www.flickr.com/photos/marylise-doctrinal/ / CC BY-NC-ND 2.0

Got a Ubuntu kernel related bug and you need help in report it? Or got an audio bug that's kernel related and you want to log the bug? Need advice or hints on how to gather kernel oops messages into a bug report? Or need to figure out how to report a bug upstream?

Well if you need this kind of help, then look no further than the Ubuntu Kernel Bug Policies wiki page. It's got a load of helpful information on kernel bug reporting and also how bug states are recorded from being initially reported, triaged, processed by a kernel developer and fixed.

We hope this will take the pain out of reporting bugs and helping you understand the bug fixing process. Kudos to Leann Ogasawara for this wiki page!