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.
Performance
- 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.
Lightning
- 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 review
- Wants to focus on performance and stability right now instead
of new features
- Also want to improve build system, test coverage
- Trying to remove all binary components (i.e., libical)
- Expected to miss 17 train, should make 24 train
- 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:
- UI is an NS-era relic.
- Editor backend is pretty crufty and needs serious work. Was
being worked on by Ehsan, now by Aryeh Gregor.
- 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
<https://github.com/mikeconley/thunderbird-ensemble>.
Maildir
- 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?)
Filters
- 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