Directions for Thunderbird
asutherland at asutherland.org
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
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
http://www.visophyte.org/blog/tag/review-board/ 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 http://www.visophyte.org/blog/tag/arbpl/ 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