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.

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.

http://blog.mozilla.com/thunderbird/

The draft document is now up for feedback and discussion and can be found here: Thunderbird Rapid Release Specifics

If you’ve got any significant feedback for discussion, please respond to the thread on our tb-planning mailing list, small feedback can be on this post or on tb-planning.

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.

There are various improvements in this version, including a revised add-ons manger:

New attachments display:

tab reordering and more. See the release notes for more details. Please submit your feedback here.

This version of Thunderbird will also work with some of our newer labs experiments including OpenSearch

and Conversations:

Give them a try, you can submit your feedback on each of those via the labs pages.

As part of this, we recently moved the Miramar nightly builds from mozilla-2.0 to mozilla-aurora so that we pick up Gecko 5.0. This will let us sync up the next releases of Thunderbird and Firefox release, and will help us to sync our plans and schedules sooner.

We’re still working out all the details of getting the various channels and repositories set up, and we’ll announce once we get those running.

In addition to this change, the Thunderbird 3.3 builds are now being generated from a different core repository; so they are now built from comm-central with mozilla-2.0.

If you want to pull 3.3 source code, then you need to do the following:

hg clone http://hg.mozilla.org/comm-central
cd comm-central
./client.py checkout --mozilla-repo=http://hg.mozilla.org/releases/mozilla-2.0

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.

For more information, please see the posts on tb-planning.

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.

Hence nightly builds on that branch have now also finished. Users on those nightly builds should consider upgrading to one of the following options:

• Thunderbird 3.1 – the latest stable release of Thunderbird.
• Thunderbird 3.1 nightlies (localised builds) – based on latest stable release of Thunderbird.
• Thunderbird 3.3 early-release builds, these are preview releases for an upcoming version of Thunderbird.
• Thunderbird 3.3 nightlies (localised builds) – the nightly builds for the next version of Thunderbird.