Brian’s Blog

In an effort to address the volume of unfixed bugs with patches we have created an Ubuntu Review Team for reviewing them. I’ve written a launchpadlib script that will subscribe the team to any bugs with patches where the patch has been added after February 1st. Depending on the throughput of that queue we will start subscribing the team to older patches. You can view the bugs the team is currently subscribed to here.

The team is also setup with a mailing list for receiving bug mail. By subscribing to the mailing list you will receive notification of these bugs with patches. The process for handling these bug reports is being documented (its a work in progress as we encounter different types of bugs) in the Ubuntu wiki.

And of course there are graphs to track the progress of the queues. Please help to make Ubuntu even better by reviewing these patches and adding them to the proper queue for sponsoring!

I sometimes find the Launchpad Release Notes somewhat lacking as they don’t mention new features added to the API. So then I either stumble upon it much later when reading the API documentation or hear about it from a friend. However, this time I happen to be well aware of some of the new API features - since I added them!

In bug, I’ve exposed ‘can_expire’, ‘heat’ (a numerical representation of the bug’s heat) and ‘number_of_duplicates’.

In bug_task, I’ve added a ‘task_age’ attribute which is the age of the particular task in seconds. This will hopefully save some calculations on the client side.

Additionally, bug has a couple of new or modified attributes, not added by me. They are ‘users_affected_count’ and ‘users_affected_count_with_dupes’ and ‘users_unaffected_count’. The ‘users_unaffected_count’ is rather interesting as it is a count of people who have marked the bug as affecting them and then unmarked it.

I’ve another branch awaiting sponsorship that will also add ‘messages_count’ to a bug.

The other week Rick blogged about some work I’d done for bughugger. I’ve written more than just some team assigned JSON queries for bughugger though.

An additional one that I wrote is for no package bug reports, it is just a json file of all the open bug reports without a package. However, you can do some very very interesting things with it. In the following screenshot I’ve filtered for all bug reports that are tagged ‘needs-packaging’ and sorted them by name.

Then of course I found duplicates! Another feature of bughugger that I’ve worked on is writing plugins for it. A plugin is python launchpadlib script for modifying a bug report or bug reports. You can see in the screenshot that I am marking bug 286716 as a duplicate of 282467. This plugin confirms the duplicate bug, adds a comment about the bug being a duplicate and actually marks the bug as a duplicate. I love bughugger’s ability to filter and sort very large groups of bugs. Combining this with the power of plugins for modifying bugs is awesome!

You can even combine multiple layers of filtering. As I going through the bugs I thought I saw a request for KBasic more than once. Here I’ve filtered on the tag ‘needs-packaging’ and ‘asic’ in the bug title.

More duplicate bugs consolidated! Looking at the ‘needs-packaging’ bug reports there is some further cleanup to the titles that could be done so it is easier to sort the list by title and identify the software to be packaged. Some of the titles had stuff like “Create Package: xyz” or “Please package: uvw”. Unfortunately, there is no plugin for mass modification of bug titles using regular expressions - yet!

However, there are plugins for tagging a bug based off the apport release information in a bug’s description. There is also one for adding any tag you want to a bug report, and another for marking a bug as incomplete and asking people to run apport-collect for their bug. The plugins are installed in /usr/lib/bughugger/plugins/ (if you want to check them out) but ~/.bughugger/plugins/ is also checked if you want to write your own. All of the features I’ve written about are available in the latest PPA version of bughugger. Go bear hug some bugs!

I’ve released a new version of the Launchpad Improvements Firefox extension and it contains a couple of notable changes. The script lp_patches.user.js is no longer included as that functionality now exists in Launchpad! This is really quite exciting and I was happy to remove that script.

However, the other day I was reviewing regression-potential tagged bug reports and trying to figure out if they applied to Karmic or Lucid. Scanning the apport information in the bug description for DistroRelease was getting tedious so I wrote a new Greasemonkey script that highlights words in bug reports.

As you can see it is highlighting release code names (Jaunty, Karmic, Lucid), the DistroRelease line from apport and the SourcePackage line from apport. In addition to these it will also highlight old releases orange and the word regression red. Suggestions of other words to highlight are welcome. The script only affects +bug pages as I found it annoying in lists of bugs. Enjoy!

Somewhat recently I blogged about specification discussion was that the tools in Ubuntu Bug Patterns should be modified to make consolidating already reported bugs easier.

I’ve improved the ’search-bugs’ tool to consolidate bugs matching a pattern into a master bug report. This can be done by using a command like the following:

search-bugs --package odt2txt --tags apport-crash --consolidate


This will mark any odt2txt bug report with the tag apport-crash and matching the pattern in the odt2txt.xml file as a duplicate. It will also add a comment about the bug being a duplicate and set the bug’s status to Confirmed.

Ubuntu Bug Patterns are a phenomenal tool for preventing the reporting of duplicate bugs and now for consolidating duplicate bugs that are already reported! Learn more about them in the README.

The 5-a-day stats are fully functional once again. All that is required to participate in 5-a-day is to join the team and ensure that your e-mail address is visible to other Launchpad users. Well that and working on some bugs! Bug work is attributed to people via e-mails to the ubuntu-bugs mailing list and the report is updated every four hours.

There are currently three categories of stats: Bug Jam, Daily and Weekly. Bug Jam Stats displays the greatest quantities of bugs hugged during an event - like the upcoming Ubuntu Global Jam! Daily stats shows who has been doing their 5-a-day for the greatest number of days in a row and who is currently on a streak. Weekly stats is similar but keeps track of people doing their 5-a-day for 5 out of 7 days in a row. So the weekend can be your “cheat” days!

Of course the source code is available, in case you have any ideas about other interesting stats we could track.  As always, if you think there is a bug please file it.

Perhaps somebody has already posted this before and I missed it!

I just noticed that Ubuntu is mentioned in the l33t subtitles  of The IT Crowd Season 1 Episode 1.  It’s rather embarrassing since I bought the DVD when I was in London in July of 2007 and just now watched the whole episode with the subtitles on.

As I was preparing a list of packages that have no bug subscribers I ran across gnome-disk-utility which has 50 open bug reports. I went to see what they were about and saw the following:

Clearly there had to be some duplicates in that list! I looked at bug 416529 as it was a fine candidate for a master bug so I could try and find a pattern to be used with apport’s bug patterns. Bug patterns are checked by apport before filing a bug report which allows us to reduce the quantity of needless duplicate bug reports and save bug numbers! The reporter is then directed to the master bug report or possibly a wiki page instead of filing a new bug. Subsequently, it is very important to be very specific when writing a bug pattern. I came up with the following:

Now that I had a pattern I wanted to test it out. Luckily, the ubuntu-bugpatterns branch includes a script called ‘test-local’ that allows one to test a local pattern against a specific bug number. ‘./test-local 416529′ confirmed that my pattern was good.

Since we already have a ton of bugs reported that might match this pattern I wanted to check all the existing bug reports. There is another script called ’search-bugs’, it was the best name I could come up with, that will take a package bug list and compare each bug against the pattern.

So indeed there are a fair number of duplicates in that bug list. I then used the ‘is-duplicate’ script, which is part of the ubuntu-qa-tools bzr branch, to set all those bugs to Confirmed, add a comment and mark them as duplicates of 416529. Voila! We have a much cleaner bug list now.

At the Ubuntu Developer Summit for the Karmic Koala the QA team discussed making it easier to install and receive updates of the Launchpad Greasemonkey Scripts project.

The result of the specification is a PPA package of a single Firefox extension that incorporates the majority of the greasemonkey scripts. In the preferences for the extension it is possible to enable or disable scripts on an individual basis.

In case you aren’t familiar with the scripts included in the extension they make various changes to Launchpad including:

• Visually identifying attachments that are patches
• Identify bug comments from the original reporter
• Prefill the comment box when converting a bug to a question
• Append karma and team membership information to people in bug reports
• Display stencils (loaded from an xml file) for tagging bug reports
• Present standard responses (loaded from an xml file) for triaging bug

If you encounter any issues with the scripts please file a bug about the launchpad-gm-scripts project.

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.