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:
  
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 <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

* Tanstaafl <tans...@libertytrek.org>:

Personally, the main thing I'd like sync support for in Thunderbird is:

1. Accounts/Settings (with option to sync passwords or not), and

2. Address Books...

So, upon first run of a new install, have an option to enter a Sync
profile username/password instead of creating a new account, which
would then simply sync all of your account settings for you (so no
need to set up your 15 or 25 different IMAP accounts for a new
install) as well as all of your Address Books.

Address Book Settings or Address Books including the addresses?
I'd favour the settings only.

p@rick

Why not the full list? If sync is the mechanism, then one should have an options dialog anyway:



Accounts (this would be in its own listbox, so you can sync them selectively)

Sync My:

• Address book - settings (what exactly is that?) - actually if there are multiple address books this probably has to be also in a listbox...
  
• Addresses
• Passwords
• Filters
• Folder tree (for POP3 / local folders?)
  
• tabs / content tabs
• extensions!!
  
• ... anythings else?
  

cheers
  Axel


--