Thunderbird projects and roadmaps

Joshua Cranmer pidgeot18 at
Wed Sep 12 02:19:39 UTC 2012

Owing to its position as the last topic discussed at the summit, this 
topic got the shaft and didn't really cover all that should have been 
discussed. So this is divided into segments: a project status update as 
reported in the status meeting and a process proposal that is entirely 
my own thoughts and on which I am soliciting feedback.


  * Ludovic is concerned about the poor state of the current
    performance. His goal is to include performance metrics as part of
    the quality assurance process.
  * Discussion of how performance testing is done in Firefox. Firefox
    uses peptests, which is a mozmill-based framework that causes tests
    to fail if the UI doesn't respond within 50 milliseconds (or
    something similar). The other suite is Talos, which measures how
    long certain operations take and posts the results to the graph server.
  * Recent discussions in m.d.planning appear to indicate that the
    current process is not stopping significant performance regressions
    from happening.


  * Fallen is the only full-time developer of Lightning right now. Very
    low rate of community contribution.
  * Support from paid staff for releases/infrastructure and Linagora for
  * Wants to focus on performance and stability right now instead of new
  * Also want to improve build system, test coverage
  * Trying to remove all binary components (i.e., libical)
      o Expected to miss 17 train, should make 24 train
      o B2G also uses/will be using ical.js, so 100% coverage will
        happen eventually
  * Out-of-date website
  * Discussion on what could be done about Linagora sponsoring

        Composer (not Kompozer)

  * Axel wants improved support for modern HTML composition. Thinks
    HTML5 + CSS composition can be a competitive advantage
  * Protz describes his compose-in-a-tab experiment; 3 things need work:
     1. UI is an NS-era relic.
     2. Editor backend is pretty crufty and needs serious work. Was
        being worked on by Ehsan, now by Aryeh Gregor.
     3. MIME composition backend.
  * Protz investigated other editors, but the Gecko editor appears to be
    the least bad at the moment.
  * Axel thinks things (UI) can be done incrementally. Protz rebuts that
    anything that needs to touch the editor backend is going to become
    very painful.
  * SM probably doesn't want major UI changes.

        Mike Conley's address book

[Etherpad had issues at this point, so etherpad notes are very 
fragmented. I've also seen this presentation basically three or four 
times, so some of this is just from memory]

  * Complete replacement of current AB code, eventually (both UI and
    backend) [incremental changes have been tried and deemed a failure]
  * Centered around notion of having many providers: system address
    book, Google Contacts, Facebook, etc.
  * Contact representation based on Contacts API with some tweaks as
    necessary for our impl. Don't worry, it will allow you to have N
    email addresses, phones, etc. Also tag-based, not list-based
  * Wireframes of various features presented.
  * Collected AB/spam whitelist are not going to be implemented via the
    address book.
  * Mike Conley needs time to work on this. Current status is no UI
    implemented yet, backend has data representation finished (with tests).
  * Mork will not be an ab provider. Probably have some way to slurp in
    old data.
  * Has prototype implementation on


  * Still buggy, but has been in tree since December 2011
  * David Bienvenu has committed to writing migration path for
    mbox-to-maildir, but no status on when
  * Discussion of benefits, basically comes down to "compact is
    unnecessary" (and allows really large folders)
  * Need someone to champion it (rkent or jcranmer?)


  * Axel mentions a list of features he thinks is missing from filters
    (import/export, copying, easy creation)
  * Full binary expression search possible in backend, but UI is missing
  * Unminuted discussion of server side filters and filter
    synchronization between instances
  * JB mentions that filters are something that fat clients should be
    able to do better than web clients

        Firefox Sync and Thunderbird

  * Firefox sync is undergoing significant changes right now
  * Sync folks wouldn't have a problem if we were syncing only small
    stuff (filters would probably be about the largest in the category).
    Syncing all email is a different story
  * Point of contact is Mike Connor (not Conley). Discussions indicate
    that he seems to be okay with Thunderbird using it, but Sync folks
    are very swamped right now.

[There was also a talk by me about new account types, but this topic 
really needs more discussion instead of a status report. Just know that 
I'm still planning on pushing it when I have a chance.]

      Processes for future development

Some of this proposal draws on themes discussed earlier in the summit, 
particularly in the governance discussion, which has yet to be 
summarized and minuted. From my mental recollection, I don't think there 
was consensus on how the project would be governed going forward: some 
were in favor of the idea that the module owners would collectively take 
the lead, while others wanted a more explicit product manager. For the 
purposes of further discussion, I'll assume that there is some sort of 
product management council which includes as members the group of module 
owners. The main importance is that there is an entity with definite 
membership that can produce a roadmap. I'll also say that this entity 
doesn't just consist of developers, but should also include people who 
represent QA and support.

Development really comes down to two separate tracks: bugfixes and 
feature development. The QA discussion resulted in a tentative agreement 
on a process for managing bugfixes (which I've called The List myself 
but appears to be referred to as the Papercuts List in the summary, but 
the two are really the same thing), so I'll omit that discussion here. 
So that leaves the question of how to manage feature development, which 
is what I'll call the roadmap for lack of a better term. This roadmap 
would contain two things: a list of features that developers are 
committed to implementing, and a list of features that the project 
management council agrees are doable and important but don't have anyone 
committed to implementing them.

Earlier, I created an etherpad to track a community-led roadmap, as well 
as a quick-and-dirty process to track rkent's papercut initiative. 
Neither of these were meant to be a long-term solution, and some of the 
results have influenced my thoughts. As was brought up during the 
summit, to survive as a product, Thunderbird needs someone who can focus 
core development. Letting the community at large contribute anything 
they wish to a roadmap would result in a long document which resembles a 
wishlist more than a roadmap. Something else is that the division into 
short-term, mid-term, and long-term is inappropriate; everything on the 
list should be realistically small and fixable things. Saying that we 
want to move from mork, for example, is simple to say, but that would 
take everyone who knows the database code working in concert months of 
concentrated effort at best. Instead, we would want to divide that task 
up into small pieces that would have a good chance of working: for 
example, identifying specific interface changes that need to be made or 
augmenting the capabilities of the database in a specific operation. 
These tasks may very well all be done in search of the goal to move from 
mork, but they represent a task that can actually be completed.

For example, here is a list of items that I think are candidates for a 
roadmap (many of these are taken from the tb-roadmap etherpad):

  * Let gloda use the JS mime parser instead of libmime
  * Complete the folder lookup service
  * Implement the sub-configure for comm-central's build system, to
    avoid wholesale duplication
  * Replace the LDAP library with OpenLDAP
  * Implement support for Sieve
  * RSS toolkit parser
  * Implement the mailbox-to-maildir converter, and switch the default
    to maildir
  * Make database headers not need to keep the database open and alive
  * Remove the closed-world assumptions of the header implementation
  * Full boolean expression filter and search capabilities

In addition to this roadmap, there is one other point I wish to bring 
up. We have several long-term wishlist items that I believe most 
developers have a consensus on in terms of 
desirability--demorkification, de-RDF, and new account types are a large 
sample--yet efforts have stalled in part because fixing them means 
making major architectural decisions that are hard to own: 
demorkification requires redesigning the database API, used just about 
everywhere; de-RDF requires actually deciding what are folder objects, 
when they are created, and who creates them, which implies a minor stall 
on the part of new account types as well (new account types also depend 
on the discussion of how to create them in the first place, and what 
services need/should be provided by core). If we are to finish 
implementing these features, then it will be necessary to actually have 
a discussion about implementations at some point. At present, I'm not 
sure we have a good venue for these discussions.

Joshua Cranmer
News submodule owner
DXR coauthor

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the tb-planning mailing list