Accepting Nominations for Thunderbird 3.0a1/3.0 blockers

Mozilla project planning, for those not in the know, happens primarily through bugzilla entries, which include bugs, feature requests, work items, everything. It may not be the best way to organize things that aren’t really software defects, but it’s what we have, and somehow it works out ok.

As a case in point, the way releases get planned (what should be in which release) is through flags — bugs can be nominated for a release (by anyone), and then a group of people with a good overall perspective on the release (called “release drivers”) either accept a nomination or reject it — or redirect it to another release. Furthermore there are bugs that are considered blocking, while others are considered wanted. The former are the bugs that we’d delay a release in order to get them fixed, while the latter are nice-to-haves, but they wouldn’t block a release.

It’s a remarkably distributed process, with discussions about which bugs should be addressed and why distributed across the bugs. We then use bugzilla queries to get a holistic picture of the release, which gets particularly important close to the end-game. Over time, I think we can build better mechanisms, but the bird in the hand…

Importantly, release planning starts with people nominating bugs for either ‘wanted’ or ‘blocking’ status. We currently have flags in place for two releases: Thunderbird 3.0a1, and Thunderbird 3. The former is imminent, the latter not so much.

For 3.0a1, our release goal is first and foremost to actually do a release, which will exercise a bunch of muscles and mechanisms which have not been exercised in a while. Nominations for 3.0a1 should focus on bugs which significantly impact the ability of alpha users to give feedback on the product. Common crashers, bugs causing data loss, and significant usability problems are the most obvious candidates. We’re not being feature-driven for this early alpha, so don’t bother nominating new features for this release.

For 3.0, we’re definitely willing to consider all kinds of bugs. These will help us scope the extent of work needed, but also help us get a broader, “crowd-sourced” picture of the state of the product — what, among the thousands of contributed ideas and bug reports, impacts the most people. The easiest way to express “support” for a bug is simply to vote on it. Don’t add comments to the bug if you’re not contributing new information beyond your support — that makes the bugs harder to read, hence harder to fix. Instead, vote on your favorites. (I know voting on bugs is far from ideal — but it’s better than any other current alternative)

To nominate a bug, you need to be logged in to bugzilla, and you should set the appropriate flag (under the CC area) to ?. Only drivers are allowed to set + or – flags, so please don’t.

For more information, see the wiki.



  1. First of all. Thank you!!! This project has so much potential, and I have grown to love Thunderbird.

    Second, and last, if I may ask, are you just taking bugs marked for Thunderbird or are you looking at “Core: MailNews” as well.

  2. BTW, bug 74157 (S/MIME tracking bug) is in Core: Security S/MIME and it cannot currently be flagged for blocking Thunderbird 3. Consider it nominated.

  3. It’s important that Thunderbird have a target userbase. Maybe that should be broad like “anyone who uses e-mail” or narrow like “SOHO power users” or something in between like “small and medium-sized organizations plus power users.”

  4. S/MIME is fully implemented (except fetching of chained certificates I think). I wonder however if a similar approach should be taken concerning SSL errors and related issues as with Firefox 3. Perhaps some discussion in that respect should be held.

Comments are closed.