Directions for Thunderbird

Andrew Sutherland asutherland at
Sat Apr 2 22:05:50 UTC 2011

On 04/02/2011 12:04 AM, Ben Bucksch wrote:
> When Linus switches to GMail web interface, surely not because he 
> likes webmail, but because it's more efficient - that shows that we 
> have grace technical deficiencies. We need to analyze those and 
> swiftly fix them. Andrew Sutherland has been great for that.
> Andrew also likes to visualize things. *Please* let him innovate 
> freely, free him from any barriers (including review), and give him 
> assistants. I think of how he wanted to use drag&drop to select 
> messages, show relations etc.. He can innovate things for TB that will 
> make people "wow", which will be highly efficient in everyday usage, 
> and which will be hard for webmail to copy.

Thank you for the kind words!  I assure you I have been given the 
latitude to innovate freely.  (I'm pretty sure I never wanted to use 
drag&drop to select messages though! :)  My innovation money is 
currently on :protz and :squib, but others are closing in on them >;).  
:protz has been doing fantastic fast-paced work on Thunderbird 
Conversations, and :squib has been churning out a stream of excellent 
and significant usability enhancements to the existing Thunderbird UI.  
:bwinton has also been doing great things with open search and other 
extensions, and Thomas Schmid has been fancying up our tabbed interface 
which had fallen way behind the state-of-the-art and now is 
leap-frogging Firefox in some ways!  And these are just the things I am 
aware of...

As you note, Thunderbird has a lot of technical deficiencies.  I believe 
this is because it has a lot of technical debt, which leads into my next 

> Dev process
> Innovations (including contributions with 1000 lines of code) are 
> stopped short to a screeching halt in their tracks by the review 
> nit-picking procedures and test requirements. I for myself have 
> concluded that it's impossible to contribute, although would have 
> liked to. This must change for TB to be alive, which is a 
> pre-condition for it to survive.

...which is that I believe that code review and tests (and code 
comments) are critically important for us to improve the technical debt 
situation and we should not relax review or test requirements in the 
name of speed or innovation.  I completely agree that they can be 
demoralizing, but the alternative is potentially much worse for the product.

In fact, I would argue that our testing requirements are a net benefit 
to potential new contributors in the sense that they make it easier for 
everyone to ensure that a patch does not break existing functionality 
and that its new functionality does what it promises to do.  The review 
burden of even a one-line patch in an untested component that does not 
come with its own tests is a function of the complexity of the component 
and its interactions with the rest of the system, not of the single line 
that is changed.  And there is a *lot* of complexity and high levels of 
coupling throughout large swathes of Thunderbird (the previously 
mentioned technical debt).

The fallout of this is that making large changes to Thunderbird, 
especially in the areas that have not gained a lot of test coverage 
requires a sizable burden of tests.  This does tend to result in a 
catch-22-like situation; no one wants to touch components without tests 
because of the huge initial test burden required, so no one writes tests 
for the component.  The flip-side is that at least those areas aren't 
gaining complicated new regressions.  But it's not a true catch-22; 
people just need to write tests for those areas.  (Unfortunately, it's a 
lot of tests and there are cost/benefit reasons to not lock everyone 
with back-end experience in a room and tell them to write tests for 
several years straight.)

Having sung the praises of tests and review, let me say that I recognize 
there are at the same time weaknesses in our current test framework 
documentation, tests, and review tools.  A test that fails and you don't 
understand why is not extremely helpful (but can still be useful).  
Likewise, the mechanics of the review process in bugzilla can be sucky.  
Various efforts are going on to try and improve these things; some by 
me, some by others.  While my review board instance (see and consider installing 
the "Bugzilla Tweaks" extension for its "review" link it adds to the 
attachment list which links to it) is probably still the best option for 
improving reviews at the immediate moment, MoCo has hired 2 fulltime 
bugzilla hackers, who should hopefully fix up the review situation 
lickety split.  Test documentation-wise, :protz has been looking into 
using jsdoc, and if that doesn't work, we will try some other options.  
Test failure logging improvements are being pursued with my ArbPL work 
(see and keep following 
tb-planning), plus MoCo has awesome QA and Automation teams doing 
development work that should be applicable to Thunderbird too!


More information about the tb-planning mailing list