My previous post about assisted landing of patches on mozilla-central was very well received. Apparently, all you have to do to get something awesome like that working is to blog about it. I chatted at the office with Chris AtLee about the idea and talked to him about what needs to be done, and who needs to own it, and shortly after, Lukas Blakk informed me that she has an intern for this job, and invited me to a meeting about the project.

Imagine this for a second. You work on fixing something, get the required reviews, and run your patch on the try server. Everything looks good. Then you set a flag or something on the bug, and go home, and enjoy your evening. The next morning, you're reading your bugmail while enjoying your coffee, and you see a message from landingbot@mozilla.org saying that the patch has successfully landed on mozilla-central, you smile, and wonder how people used to spend 4 hours watching the tree (and possibly getting yelled at by me or philor in the meantime) when they wanted to land something on mozilla-central.

Writing tests which are resilient against intermittent failures is hard. In the process of trying to fix a large number of intermittent orange bugs, I've found out that a large portion of them are just caused by mistakes in writing tests, and almost all of those mistakes fall into commonly reoccurring patterns. It's hard to avoid those mistakes, unless you know how they lead to intermittent oranges, and how to avoid them.

When debugging a test, I've sometimes found it useful to have access to an extension such as DOM Inspector or Firebug to debug what's going on with the test. In the past, you could do this by a bunch of hacks to make sure that you get the extension inside the test profile folder in time so that the test harness doesn't delete it for you. But last week I landed a patch which enables you to do this more efficiently.

I've started to believe that commit messages are a very important part of our code history. I think that they should provide a clear description of what the change does, what's the corresponding bug number, who reviewed and approved the patch, etc. I think you should even include a lengthy description of why the patch does what it does, if needed, in a multiline commit message, like this. We've started to use some magic tokens like CLOSED TREE and DONTBUILD which are not really part of the changeset you're pushing, but instruct our automated tools to modify their behavior.

I have good news for you! A while ago, Shawn convinced me to move the source code to the Bugzilla Tweaks add-on to bitbucket. I did that, and lo and behold! We now have two contributors to the add-on! Steve Fink, and Heather Arthur, are the two wonderful people who sent me emails out of the blue and told me that they want to improve the add-on! And they were not kidding!