Thunderbird projects and roadmaps
pidgeot18 at gmail.com
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
* 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
* 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
* 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
* 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
* 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
* 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.
News submodule owner
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning