Blake (old posts, page 14)

More hurray!

A while ago I had my first patch to Thunderbird committed.

Today I pushed my first patch, all by myself.

It’s kind of exciting, having checkin privileges. It means that I don’t have to wait for someone else to check in my changes once they’re accepted. But on the downside, it means that I’m the one who has to do the commit, and watch the Tinderbox, and if anything goes wrong, I’m even more on the hook than I previously was. (Well, that last part isn’t really true, but I feel way more nervous than when I could just add “checkin-needed” to the bug, and not worry about it anymore.) And basically there’s just a lot of new stuff for me to keep track of, and figure out. But since anything I do is going to show up in the official history, I need to figure it out before I do it, which always adds a little pressure, which in this case is probably a good thing.

Building Thunderbird Faster

I’m always looking for ways to speed up my Mozilla build, since it allows me to test my changes even quicker. I was really excited when I found out about make -s tier_app, since it sped up my compiles by a huge amount.

real    10m22.630s
user    4m28.072s
sys     1m27.807s


make -s tier_app
real    0m14.426s
user    0m6.502s
sys     0m3.957s

But yesterday, on IRC, I heard about libs_tier_app, which is ever faster, if you haven’t changed any IDL files (which I usually don’t).

make -s libs_tier_app
real    0m9.407s
user    0m5.440s
sys     0m3.065s

Okay, it’s not nearly as good as going from 10 and a half minutes to 15 seconds, but a 30% (or is it 50%) speedup is still nothing to sneer at.

More notes on Mercurial.

Recently, I made some changes to my work flow to get around some slight annoyances. Specifically, I switched from using mq to using pbranch. The features that pbranch gives me that mq didn’t basically boil down to two main things; sharing, and tracking.

With pbranch, it’s way easier for me to share my changes, both with other people, and with myself in a virtual machine. It is possible to share the patch with mq, by cloning the patch repo if I remembered to run qinit -C, but with pbranch all I have to do is clone the main repo, and my changes are right there, waiting for me.

For tracking, when I’m nearing the end of a patch, and it mostly works, I get really nervous if I can’t check in my changes. With mq, I set up an alias to let me commit the patch queue, so that I could go back, but it was really hard to tell what I had changed between any two commits, since it was showing me the diff of my diffs. And so I didn’t use it as much as I would like to. With pbranch, I just commit the code, like I want to, and it keeps track of what the patch should look like.

So, my day-to-day workflow now looks more like this:
If I’m working on a bug that I’ve already got a patch started for, I cd to the appropriate branch, type hg pgraph to see where I am, and hq update branchname to get to the pbranch I want to work on. Then I make my changes, and when I’m happy with the results of hg diff, I type hg commit to put the changes into the pbranch. After that, I use hg pdiff > ../branch-name-bugnum-description.diff to get a patch that I can upload to bugzilla. At this point, I usually load the patch into Vim, and search for some of the mistakes I’ve made in the past. (/^+.*[[:space:]]+$, and /dump caught a lot of my initial mistakes. Now I’ve moved on to things that are tougher to check for, like putting open-parens on a new line instead of on the previous line.) I usually go through a couple of cycles of hg commit/hg pdiff … before I’m happy with the patch. Once I am, I don’t have to type anything before I upload it, since it’s already committed.

Another reason to use Mercurial (or Git or Bazaar)

A lot of the code I write for Thunderbird has to work on all the platforms it supports. Since I don’t own a Linux or Windows box, and don’t really want to waste the hard drive space on my MacBook Pro with a dual- or triple-boot setup, I’ve decided to install the other operating systems on virtual machines. (I’ve chosen VirtualBox, because it’s free, and I’m cheap. As an added bonus, it works quite well, too.)

If I was forced to use a centralized version control system, this would lead to a bunch of pain, since I wouldn’t want to check in a half-finished patch, but I would still really want to see what changes I made for one OS, to try and figure out what changes I need to make for the others. And I would want to be able to keep a record of what I did, step by step, so that I could undo stuff if it turned out to be a bad idea. (Hey, that sounds like a perfect task for a version control system! ;)

Since Mozilla uses Mercurial, I didn’t have to deal with any of that. I had my repository on the host machine, which I had cloned from the main repo, and I just cloned it into each of the virtual machines. Whenever I started a VM, I pulled the latest set of changes from the host machine; As I fixed stuff on that platform, I committed to the repository on the virtual machine; And before I shut down the VM, I pushed my changes back to the host machine. When I wanted to see which changes I made to get things working for the platform, it was easy, and propagating those changes to the other virtual machines was also easy.

When people talk about the advantages of distributed version control, a lot of the time they mention being able to still commit your changes when you’re on an airplane, and sharing in-progress changes with other people, but for people like me who do mainly self-contained stuff and don’t fly anywhere, supporting multi-platforms with virtual machines and still being able to track my changes might just be the killer feature.

Thunderbird 3.0 beta 3 shipped!

It’s true, after a lot of hard work, and a few hard decisions, the first version of Thunderbird that has code of mine in it has shipped. Dan Mosedale has some comments on what’s changed. If you like Thunderbird, please download it, give it a try, and let me know what you think!

On a more personal note, the thing I did on this release that I’m the most proud of was to add a button that lets you reply to a mailing list.

Reply to a mailing list

I’m proud of it because it feels like a neat-but-still-usable UI, and because it is one more step on the road to getting people to change their mailing lists to not munge the Reply-To header. (With this patch, you are given the option of replying to the list, or the author. Unless the list has set the Reply-To to point to the list, in which case you can only mail the list.)

A couple of the other areas I worked on for this release were updating the Activity Manager so that it didn’t hang when you clicked “Clear Now”, and so that it merged a bunch of move/copy/delete notifications into a single notification that told you how many messages had been processed; and fixing a some layout and logic bugs in the Autoconfig dialog (which you get to from “File » New » Mail Account (Quick Setup)…”). Yeah, the Autoconfig dialog is still kind of ugly, but it’s better now than it used to be, and I’m working on making it prettier for beta 4.

My first couple of days at Mozilla Messaging.

A few weeks ago I started a new full-time contract at Mozilla Messaging (a.k.a. the people who brought you Thunderbird). I meant to post this on the Wednesday after I started, but didn’t get around to it until now. So, here you go, my notes from just after I started a new job.

It has been a pretty crazy couple of days, both because I’m not that used to working for a full 8 hours on one thing, and because I’m at the point where there’s still so much to learn that I could spend all my time researching stuff, and never get anything done.

But even with all the stuff for me to learn, I feel like I’ve made a fair bit of progress. There were a few bugs assigned to me, based on a previous patch, as well as a couple of things left to do to get the feature working, so I jumped right in to those. After I had new patches up for review on all of those bugs, I talked with Bryan Clark about what bugs I should tackle next. He and David Ascher both suggested that the new automatic mail server config dialog could use a bit of love.

This morning, I did some investigation on group email addresses for one of the bugs I’m working on, and took a look at how the autoconfig dialog was put together so that I wouldn’t sound like I was completely lost in the meeting. (XUL, CSS, and Javascript. No surprises there. :) Then, after the Status Meeting, Bryan and I chatted a bit about what the various bugs were that he had assigned to me, and what sort of things I might look into to try and fix them. A few hours later, I had a fix for one of them, and applied a similar fix to another. (As an aside, you’ve got to love the 3 hour investigation which ends up being a 9-character change. At least while investigating the bug, I learned a lot about hboxes, vboxes, flexes, grids, and descriptions, which will hopefully come in handy in future bugs. :) Finally, I ended the day by reading a review of a patch I submitted on Monday morning, making some tweaks to my code, and resubmitting it.

The final thing that amazes me is that each day is taking up pretty much a full page of my log book, which is way more than usual. Most of the days last month got a line or two. Really full days would maybe get half a page. But yesterday and today were a solid page, chock full of information, each. I wonder how long this trend will continue. I hope it keeps on going like this for a long time.

An odd coincidence?

I have a theory. (No, it’s not bunnies.) One of my favourite foods is soy beans. I love it both because they’re tasty, and because they’re so changeable. I mean, what other substance can be used to make a hard white solid (tofu), and a viscous black liquid (soy sauce)? Hey, waitaminnute. “Soy beans” are oil! It’s all just different names for petrochemicals!

How I use Mercurial (and the MQ extension).

I started working for Mozilla Messaging a while ago, and since David Wolever asked me how I used Mercurial and the MQ extension, I thought I would put up some notes on how I’m currently using them in my day-to-day work. Of course, the stuff I’m doing now is a little different than what I’ve done in any of my previous jobs, so I’m not sure how useful any of the following will be to anyone who isn’t contributing to an open source project.

First, let’s talk a little bit about how I have my Work directory set up. The first thing I did when I started working on the Thunderbird source code was to pull down a clean copy of the source into a directory named “src-base”. The purpose of that directory is to always contain a clean copy of the upstream source code so that when I want to update the various branches I have (five, at last count), I only need to download the changes from the Mozilla repo once, and I can then propagate them from src-base to the other branches. I got the idea to do that from the Bazaar-NG developers, and I think it has helped to keep my bandwidth usage down. It might cause a problem if I was sharing my branches, but since Thunderbird seems to revolve around submitting patches to bugzilla, it works out pretty well.

The next thing I did was to clone src-base into a directory named “add-reply-list-button” (because I was writing a patch to add a Reply-To-List button :), go into that directory, and type hg qinit -c to create an mq repository, and put the mq repository itself under version control. (I didn’t actually do that the first time, and was quite annoyed that I couldn’t revert changes I had made in my patch queue.) The other part of that is that I’ve aliased mq to hg -R $(hg root)/.hg/patches. This lets me type mq commit to commit the changes to the patch.

So, now we’re at my day-to-day work. If I’m working on a bug that I’ve already got a patch started for, I cd to the appropriate branch, type hg qseries to see where I am, and hq qpush or hg qpop to get to the patch I want to work on. Then I make my changes, and when I’m happy with the results of hg diff, I type hg qrefresh to put the changes into the patch. After that, I use hg qdiff > ../branch-name-bugnum-description.diff to get a patch that I can upload to bugzilla. At this point, I usually load the patch into Vim, and search for some of the mistakes I’ve made in the past. (/^+.*[[:space:]]+$, and /dump caught a lot of my initial mistakes. Now I’ve moved on to things that are tougher to check for, like putting open-parens on a new line instead of on the previous line.) I usually go through a couple of cycles of hg qrefresh/hg qdiff … before I’m happy with the patch. Once I am, I type mq commit -m "Updated patch to fix foo and bar." to save the state of the patch, and then I upload it.