Brian’s Blog

For a while I’ve thought it would be great to be able to search for bug reports with bazaar branches associated with them. Unfortunately, this functionality does not exist in Launchpad yet. As an interim solution I’ve written a report using a database query that looks for bug reports with open bug tasks that have a branch, that is not merged or abandoned, associated with them. Come to find out there are quite a lot! 218 to be precise.

I suggest that we start reviewing these and either merge the branches or remove them from the bug report before these contributions become stale and the list becomes unmanageable.

I’ve started looking at upstream Debian bug reports a bit more and noticed that there are quite a few unfixed bugs with patches there too. It then occurred to me that these might make a great opportunity for harvesting into Ubuntu!

I’d worked with the Debian bug tracker SOAP interface before and thought I could make use of this to find Debian bug reports with the tag patch. Sure enough it was fairly trivial. A search is now performed for bugs that are tagged ‘patch’, are not user tagged ‘ubuntu-patch’ and are not tagged ‘wontfix’. The results of this search are then output in a csv file that is used by harvest. Now in harvest we have three places to look for patches (Ubuntu, Debian and Fedora) to help improve Ubuntu packages.

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.

A long standing feature request of the Launchpad Greasemonkey Scripts project has been the ability to share stock replies. We have a bunch of commonly used responses, but they don’t exist in the stock replies greasemonkey script unless you entered them yourself.

Well, I should say didn’t! because, thanks to Kees (with a wee bit of help from yours truly), now they do.  The script grabs an xml file which contains the majority of the commonly used responses.  These are then added to your existing stock replies or used to preseed them if you don’t have the script installed.  Additionally, if the xml file is updated you can also pull in the changes by clicking “+reload+”.  If you don’t want to do the work of clicking “+reload+” the script will check for you every three days.  The editing of stock replies has also been reformatted so it is easier to read and edit the comment being added to the bug report.

So install the latest version by clicking on the green download arrow on the right hand side.  In the event that your favorite response is missing from the xml file please file a bug about the launchpad-gm-scripts project and I’ll get it added.

I recently updated the firefox-launchpad-plugin in Jaunty, with Steve Beattie’s help, to include a search for bugs in Launchpad using a bug number and a shortcut for a package’s bug listing page.  The latter is much easier than url hackery of http://bugs.launchpad.net/ubuntu/+source/calibre.  In addition unique images, the same as those used in Launchpad, have been added so it is easier to identify each search.

For those of you still running Intrepid it is possible to install the Jaunty package.  Additionally, the keyboard shortcut for accessing the search is Ctrl+k and Ctrl+ arrow key moves up or down in the list.

The Launchpad Greasemonkey Scripts project includes a script that makes it easier to add tags to a bug report by presenting hyperlinks of commonly used tags.

I’ve updated the script so it is now possible to have tags defined for specific projects, like Inkscape, or for specific packages in Ubuntu. There are some existing tags defined for any Ubuntu bug report in addition to package specific tags for openoffice.org, network-manager and update-manager.

If you want to add more the format is:

{"tag":"cdrom-upgrade", tip:"Related to an upgrade from CD-ROM or DVD media", "project":"ubuntu", "package":"update-manager"}

Where tag is the name of the tag, tip is displayed on mouseover, and project and package define when the tag will be displayed. When adding tags for just a specific project you can omit the package key and value.

In the past couple of weeks I’ve been writing a needs-packaging bug reviewer that creates a report regarding possible actions for bugs tagged needs-packaging. I’ve gone through quite a few of these myself and tagged them as ‘auto-search’ if the report led me to act on the bug.

The script looks at bugs without a package that are tagged needs-packaging and parses the bug’s title, ‘[needs-packaging] software …’, extracting the first word after ‘[needs-packaging]’. This word is then searched for using rmadison (for Ubuntu and Debian) and Debian wnpp (Work-Needing and Prospective Package) bug reports. The searches used and possible actions follow:

1) Search - ‘rmadison software’ - Ubuntu’s repositories are searched for a package name matching software. Action to take - In the event that the software is the same as the one described in the bug report the bug should be closed as “Fix Released” and information given about in which release of Ubuntu the software can be found.

2) Search - ‘rmadison -u debian software’ - Debian’s repositories are searched for a package name matching software. Action to take - In the event the software is the same as the one described in the bug report the bug should become a sync request, or a new bug submitted using the sync request format. Generally speaking, the package will be available in the next release of Ubuntu when packages are synced with Debian.

3) Search - Debian ITP (intent to package) bug reports are searched. Action to take - In the event a match for the same piece of software is found an upstream bug watch for the particular Debian bug should be added. This will inform potential packagers that Debian is also looking for this software so they could try and have the package also included in Debian.

4) Search - Debian requested package bug reports are searched. Action to take - In the event a match for the same piece of software is found an upstream bug watch for the particular Debian bug should be added. This will inform potential packagers that Debian is also looking for this software so they could try and have the package also included in Debian.

Additionally, in the event that there is not a clear package name for a piece of software - like ‘[needs-packaging] Ruby Nmap::Parser Library’ it is possible to tag the bug as ‘np-reviewed’. The script will ignore any bugs with that tag. While you are welcome to run this report locally I’ve setup a cronjob on people.ubuntu.com to run it weekly. In the event that you do take any actions on needs-packaging bugs because of the hints provided by this report please tag them as ‘auto-search’.