A few weeks ago I made some changes to my account with my ISP and was expecting to loose my webspace (intentionally, due to a better deal all round). At the time I started getting a new blog set up.

As it turns out, and as you can see, this blog is still here. However, I’ve decided to move all my Mozilla & Thunderbird related posts to the new blog anyway.

I haven’t quite decided what to do with this old blog yet. For now, it’ll just serve as an archive for my old posts; I may do some more personal posts at some stage and re-purpose it, but I need to think about that more first, so we’ll see.

From around the time of the Thunderbird 3 release, Thunderbird’s trunk nightly builds were code-named Shredder. Following the switch to the rapid release cycle, we’ve now changed these to be code-named Daily.

They’ve got a shiny new logo to go with them as well, which completes the set for our rapid releases:

This change will take place from the next round of nightly builds. You’ll be able to obtain them here (Localised). If you want the slightly more stable builds of Earlybird or Beta, then check out our channels page.

Something I know we’ve been missing since switching to the rapid release process, is a document saying what we are doing and how we are going to be working, reflecting the documents that Firefox wrote.

Therefore you can now test your add-ons with Thunderbird 5 Beta, and increase the compatible versions accordingly.

We are looking into the compatibility bump mechanism that Firefox is using on amo, but we’re not sure when we’ll be able to use this yet. In any case, now is a good time to check out the Thunderbird 5 Beta, and test your extension at the same time.

In this latest version of Thunderbird we’re picking up the changes in the core toolkit that revised the add-on manager for Firefox, so for instance, you may need to make changes to your manifests if you’re using components. You can find more information on these changes and others within Thunderbird from the Thunderbird 5 for Developers page.

Builds for the “new” trunk can be generated from comm-central with mozilla-central (and for now will be identified as 3.4a1pre), we’ll be setting up builders for these in the next day or two. Note that nightly builds will not be available for a while, as our focus is on Thunderbird 3.3.

As you may have seen, over the last year (especially the second half), the Thunderbird team have been looking at improving interactions with external contributors to help both Thunderbird development and the contributors. Most of these thoughts have been on Dan’s blog.

Over the last few months of last year, one of my tasks was to work with the various Thunderbird reviewers to get the backlog of reviews in the Thunderbird product cleared down. We almost managed it towards the end of last year, but now we’re in the position that we have no reviews over a month old outstanding (and had we not just had the Christmas holidays, the list might be even shorter). ui-reviews are almost in the same position with a month and 2 days being the oldest.

Some of the old reviews were obsolete, some need more work, and a few were reviewed and pushed through as the original contributor was no longer available.

The fact we’re now down to all reviews being less than a month old is a great improvement over the 50-odd outstanding reviews at the start of last year. Here’s a graph showing the number of bugs with open review requests over time in the Thunderbird product since June 2009:

This all means that we can now start this year from a better baseline, and we’ll be able to easily identify reviews that are taking a long time and see if we can move them forward more quickly (e.g. by re-assigning, reminding, helping etc.). I feel this will help our contributors by giving timely reviews, or at least feedback as to when reviews are likely to happen.

I’m also going to be looking at the Mailnews Core product reviews at the start of this year, at the time of writing, there are about 50 outstanding reviews, some going back to 2004. It is quite possible that some of these are obsolete, but I’d like to look through them and try and make sure we land what is sensible to get landed.

Review Times

The other thing I’ve been pondering over the last few months is review times. Back around Thunderbird 3 we knew our contributors were not happy with the length of time it took to get review, so I’m looking at actually getting some figures to quantify that and set future targets.

Over Christmas I had some spare time, and rather than do things directly on Thunderbird (because that’s definitely work), I chose to investigate the bzapi and the bztools (because its something new and not what I currently do as work). As a result, I came out with a script, that gives a very sketchy estimate of average review times across a product (or particular search).

I say sketchy, because it doesn’t take into account multiple review requests for the same attachment (it takes the time from the first review being requested to the first review granted) and it doesn’t deal with cancellations or other changes.

So across all the bugs in the following products in bugzilla.mozilla.org, here’s the summary of average review times (rounded up a bit):

Thunderbird: 6 days 3 hours

MailNews Core: 11 days

Toolkit: 6 days 2 hours

These reflect the entire set of bugs in one product from the beginning of bugzilla until now, i.e. many bugs, years and people, some of whom no longer contribute – so it is not going to be really useful to draw conclusions from these, but I thought folks may be interested in the overall numbers.

I’m hoping to extend the scripts with some better data gathering and probably insertion into a database (unless someone has done this already!), then I hope to analyse on items like review times for reviews requested in a particular year, and average review time compared to the attachment size.

As the script is currently very crude, I won’t publish it just yet until I’m nearer the database stage – what I have is fairly easy to work out if you really want to.