Infinite Knots

It's now possible to retrieve the list of packages that a given team supervises.

This may sound like an obscure feature, but it enables a very powerful way to increase the scope of automated bug handling scripts.

I've been mentoring Kamran Khan for Google Summer of Code for the Ubuntu project this year. He's working on a variety of improvements to Arsenal for making bug triaging easier.

In addition to the attachment forwarding script I mentioned earlier, Kamran has created an improvement to Launchpad for listing packages that a team is subscribed to, which I helped him get landed into Launchpad this week.

A long while ago I hacked together a simple bug upstreamer tool, which I've used quite routinely since then for forwarding X.org bug reports against the -intel or -radeon driver from Launchpad to the Freedesktop bugzilla.

Recently, I've been working on generalizing and improving this tool, with the objective of making it generally available to the community for upstreaming bugs from any Ubuntu source package to any upstream Bugzilla instance.

When a launchpad bug gets a lot of comments, displaying the bug page can take a long time. To mitigate this, Launchpad only shows the first 80 comments in such a case. But often what you actually want to see is the *recent* activity. So to get that you have to go through an additional page load, which is annoying.

To fix this, I've landed a change to bugs.edge.launchpad.net today which displays the first 40 and last 40 comments. As an example, see bug 541511.

I changed the comment/activity display algorithm a little bit in order to do this, which as a side effect improves the performance a very slight amount (about 1-2% faster for highly commented bugs).

I had the need to have "last updated date" shown on an html page that I am maintaining in bzr, and wondered if bzr supports that feature.

It does, with a plugin. Here's how to set it up.


# Installation
bzr clone lp:bzr-keywords
mv bzr-keywords ~/.bazaar/plugins/keywords


Next you have to configure bzr by adding rules for what file types to do the keyword expansion on:

# Configuration
cat <> ~/.bazaar/rules
[name *.c]
keywords = on

[name *.html]
keywords = xml_escape
EOL

Finally, here's an example of how it's put into practice:

# Usage
mkdir /tmp/foobar
cd /tmp/foobar
bzr init
echo 'Last updated: $Date$

Looked like we've finally gotten boot speed of X down under a second, as measured by Martin Pitt on his box. (Our objective for Lucid was 2-seconds so this is quite good news.)

gtg 0.2.1 is released today. This release includes a feature I added for deferring tasks to a later date, so I figured I'd share about how I use it for scheduling my own todo list.

I've got a huge todo list. Work projects, bugs needing fixed, hobby software projects, baby stuff, family stuff, house maintenance... Hundreds of tasks taken all together. It's overwhelming when you look at the full list all at once.

The Work View feature in gtg is helpful because it lets you look at just a subset of the whole list. The Work View excludes tasks that have a start date scheduled for some day in the future.

So the trick I use is to set start dates on every task. By default, new tasks do not have start dates. So when starting out with gtg, setting start dates on each and every task can be a huge amount of work! This is where the defer functionality comes in handy.

In the task browser, turn on Work View. Now highlight a range of tasks that don't have a start date scheduled, which don't need to be done for a long time. Hit the right button to bring up the context menu, and go to "Schedule for... > Next month". How many tasks remain? If it is more than 10-20, pick highlight another set of tasks that don't need to be done right now, and do "Schedule for... > Next week". Repeat this moving tasks to tomorrow, until the list is whittled down to a set that can be achieved today.

I often find I overestimate what I can actually get done. Some tasks take longer than I planned. Interruptions, requests and emergencies steal time too. So as the day goes, I'll postpone items to tomorrow if it's looking unlikely that I'll get to them, so that I can stay focused on the important priorities.

Each morning, I refresh gtg's work view to get the new todo list for the day, and repeat the above process to narrow the list to just 20-30 items. I usually take a mix of high priority tasks, lower priority tasks that won't take much time, and a few fun items.

Next Thursday (Feb 4th) evening several of us from Canonical will be getting together after work to talk about and hack on gtg. If you're in Portland and interested in showing up, drop Jorge Castro a line, he's organizing it. (Or leave a comment here with your contact info and I'll pass word along).

I'm getting to be a heavy user of gtg. As you can imagine, being the X maintainer for Ubuntu engenders a huge task load. For example, in addition to regular project assignments, bug work, packaging duties, and so on, there are also a lot of "drive by tasks" given to me by other people on irc, email, etc. In the past, while I had tools for organizing projects, I never did have a good way of capturing and organizing these drive by tasks, so they tended to either a) interrupt whatever I was working on that day, or b) get dropped on the floor and forgotten. With gtg, what I do is write down a task for the item (or forward the email to gtg, or cut-and-paste the log from irc), and defer it until tomorrow. Then I can assure the requester that it is on my todo list for the next day.

So while it doesn't solve the task overload that comes with maintaining X, it sure helps with managing the tasks in a more organized fashion.

Here's my latest gtg hack...

I get a ton of email, some of which requires me to do some action. If I can't do it right away I stick it in a Todo folder, but this is bad because it's too easy to ignore. What I really want is to be able to send the email into gtg as a task.

Fortunately, mutt is really extensible! Here's a simple macro to send tasks to gtg when I hit the 't' key:


macro index t "<pipe-message>gtg_new_task --interactive Follow up:<enter> <save-message>+Todo<enter>"


In addition to sending the email to gtg, it also moves it to the Todo folder, so it's out of my inbox and still available for reference.

gtg_new_task is a command line program which communicates with gtg via its dbus api to add a new task. I had to make a few small modifications to it to get it to accept input from mutt, so use my commandline-tools branch.

I only just got all this working last night, so I don't yet know how useful this will really be in practice, but it seems like it could be extremely handy. It makes processing my email inbox faster since I can 't' emails I need to do something about with the confidence that I actually *will* deal with them, and gives me the ability to schedule *when* they're done, group similar ones with tasks, get them to show up in my weekly status report when they're done, and so on.

Here's how to make bzr paginate its output:

$ mkdir -p ~/.bazaar/plugins
$ bzr branch http://bzr.oxygene.sk/bzr-plugins/pager ~/.bazaar/plugins/pager

You can verify the 'pager' plugin is installed like this:

$ bzr plugins
...
pager
Run commands producing long output in a pager ($PAGER or less).

Various other handy looking plugins can be found at http://wiki.bazaar.canonical.com/BzrPlugins

Me and rebates are like Charlie Brown and the football. There are so many different ways the rebate companies arrange things to trip you up so they can reject it. I know it's 90% likely no matter how careful I am there will be some nit-picky detail I overlook, and so end up wasting all my time and then get pissed off over some $10 or whatever.

I already don't factor in the rebate when doing price comparisons, but I'm to a point I'm thinking of just boycotting any product that is priced with one.

I filed my first status report using my gtg status report exporter. Sweet. I need to fix up a few things before this can go upstream, but it was so nice not having to rack my brain "What did I do last week?" in order to write status.

Meanwhile, today I implemented a tool to import my Ubuntu blueprint work items into gtg. When we write blueprints, one of the steps is to itemize all the tasks into the whiteboard. Pitti has a scraper which gathers all these together and generates json reports.

I crafted an import plugin for gtg to load these json files into gtg. You give it the json file's url, it loads it and asks which username belongs to you, and then imports all your assigned blueprint tasks. I've stuck the code on a bzr branch.

Lately I've been experimenting with gtg for managing my tasks. My job requires that I provide a weekly status report of work I've done over the past week. So I added an option to gtg's export plugin to export tasks marked finished in the past 7 days.

Maybe I can get my status reports done on time now. ;-)

Once in a while in looking through bug reports I find one that makes me go, "Wow, that guy knows how to report bugs!" The report is clear, specific, and easy to drive to a solution. Then I look at the vast number of bug reports that languish in the bug tracker and realize that making good bug reports is a skill we need more people to have, if we're going to succeed at improving Ubuntu's quality.

First, I think we need a better term than "bug report". The way we use launchpad, "bug report" is a broad term which could include everything from a packaging change request to a support request to a plain old complaint. Let's just consider those bug reports which describe a distinct, confirmed breakage of the software in question. In software quality circles the term "Defect Report" is used, and that sounds suitable.

Lots of people have written about how to make a good bug report, but in thinking about it there's one thing above all which defines a good report: The original reporter is not needed for any further work on the bug. In other words, all the data necessary to characterize the bug is there, it's pretty clear what has broken, and the steps to reproduce it are known so we can verify the fix solves it. If there are bug reporting guidelines or troubleshooting procedures for the software package in question, they've been followed.

If you think about how often we have to ask the original reporter to supply more information, try testing some configuration variations, and so on, you realize that a lot of bug reports don't meet this criteria! In fact, if you think about it, these really are what you'd call support requests... where the (implied) request is for support in how to craft a valid defect report. ;-)

Been experimenting with turning logs into lumber using this horribly awesome juryrigged sawmill.

Steve Langasek cut down a walnut tree in his yard and gave me the wood. Apparently hardwoods require 4 years to dry after slicing into boards. Maybe I can turn it into some nice toys for Dutch one day.

Just got the new Inkscape book. Dutch says he thinks it's great and all but does it remove red eye?