Brian’s Blog

A bit ago I wrote up a wiki page regarding what qualifies as a patch and how to work with patches in Launchpad. Part of this process involves properly flagging attachments as patches and ensuring that all attachments flagged as patches really are patches! While its rather easy to flag an attachment as a patch after the fact (edit the attachment, check the box), its not so easy do that and a comment to the bug report.

I’ve written a couple of tools that’ll make this process a single step and they are included in the ubuntu-qa-tools project in Launchpad. check-patch-comment.py can be used to flag an attachment as a patch and a comment pointing people to the Bugs/Patches wiki page, while uncheck-patch-comment.py flags an attachment as not a patch and adds a similar comment. I hope that using these tools in conjunction with the open bugs with patches report and the possible patches report we can integrate more of these patches in Ubuntu and also get them forwarded upstream.

Now that the final release of Jaunty Jackalope is rapidly approaching, it is important that we keep on top of Jaunty bug reports. To aid in doing this I’ve created a bug report that includes bug tasks created since the Beta was released.

The report only includes bug tasks that are in a New or Complete status using the theories that the bug is missing information if it is Incomplete and somebody who knows what they are doing looked at it if it is Triaged. The report also includes a new feature I’ve been toying with - bug gravity. The bug gravity is an attempt to determine which bug reports should be looked at first based off properties of the bug like who reported it, tags, number of subscribers, number of duplicates, numbers of users affected and whether or not it is private. The legend for how gravity is computed appears at the bottom of the report. Another thing I added was information about what component a package appears in - you can see it by mousing over the package name.

I’ve also added the script, bugs-since-sometime.py, that generates the report to the ubuntu-qa-tools project in case you want to see bugs since some date. I plan on modifying the date criteria for the report after the release candidate comes out.

The Ubuntu bugs mailing list contains a wealth of information. I was curious about how often bugs are reported using apport whether it be from an application’s “Help -> Report a Problem” menu entry, using ‘ubuntu-bug’ or ‘apport-cli’. These are identifiable by the presence of the tag ‘apport-bug’. I’m curious because these are the preferred methods for filing bug reports since a wealth of information is gathered automatically. The answer is a depressingly small amount.

While the number has increased in the past couple of months it is only a slight increase. Which is surprising because everyone benefits when you use apport to report a bug about Ubuntu. The reporter doesn’t need to manually add their release of Ubuntu, package versions or log files. The triager doesn’t need to ask for that information and can more easily triage the bug report. The developer has a lot more information accessible to them to work on the report.

So when you report a bug about Ubuntu report the bug using apport!

As a part of the Jaunty release cycle there has been some focus on fixing bugs. There isn’t really a great way to track bug fixes though. Let alone finding out things like:

* Who has closed the most bug tasks by uploading packages that reference a bug number in the changelog?
* Who has fixed the bug task that has been open the longest?
* How many bug tasks have I closed by uploading packages?

Subsequently, I’ve written a report that attempts present this information in a useful fashion. I’ve also created reports for various teams within Canonical. If you don’t show up on your team’s report its because you’ve chosen to hide your e-mail address in Launchpad. Now, what kind of interesting things can we find out from it?

* Sebastien Bacher has uploaded the fix for the oldest bug for Jaunty at 1616 days.
* Kees Cook fixed the oldest bug of all the server team members at 903 days.
* The smallest bug number fixed is bug 1568 (four digits!) by Arnaud Quette.
* I’ve fixed 12 bug reports using changelog closes. (Its interesting to me!)
* A surprising number of bug fixes take less than 1 day.

The report is generated by a script that parses the -changes mailing list for “Launchpad-Bugs-Fixed:” and grabs the “Source:” and “Changed-By:” lines. The Launchpad API is then used to look for a bug task for that source package and bug number, subsequently bug tasks might not appear if the bug report only has upstream project bug tasks. The Launchpad API is also used to find the date_created and date_fix_released, in the event either of those are empty the bug task won’t appear on the report. Some bug reports are also so private that I can’t see them so they won’t show up either.

There is also a report using the Intrepid changes mailing list that might be interesting to compare to Jaunty. Unfortunately there is not one for Hardy or any previous releases because date_fix_released didn’t exist in the database before then and subsequently isn’t populated.