Thunderbird/July2012AndBeyond

Here is a list of the comments we received so far on TB-Planning. Our goal here is to gather all of them on the same page to get conversation "started"

Tanstaalf: long standing issues – like the buggy HTML editor, - buggy IMAP behavior, - the new Address Book, - maildir vs mbox for local storage, - full integration of the Calendar (Lightning extension), as just a few examples

ben bucksch What we're still lacking in professional setups is a calendar. Lighting is almost there. We just need to ship it and then polish it.

Alan Lord I can't tell you how many times I've seen question on the OpenOffice (now LibreOffice) lists asking about an Outlook 'component' - maybe now is the time to start discussions with them about some kind of collaboration under the Document Foundation umbrella?

Robert Kaiser: ...as Mozilla seems to stay open to supporting community-driven innovation in new releases. The main thing is to get community people to actually work on it, the organizational stuff seems to be no hindrance at Mozilla at this time, so also no need to think about alternatives.

Tanstaalf: The Document Foundation is set up specifically to allow other projects to fit under their umbrella - it is *not* only for LibreOffice, or even for Office Suites.

Yes, Thunderbird is a Mozilla Project - for now - but with the announcement currently being debated, there is a possibility that this will no longer be an advantage soon, so all I'm saying is we should be cultivating options.

Kai Engert - ehsan akhgari The one thing I'm worried about is regressions: Firefox and Thunderbird share application level code that is responsible for the correct functioning of security protocols. I'm worried there are only two approaches to this dilemma. (a) Tell developers to do what I suggested above - keep core functionality - implement new core functionality in addition. This strategy would be very helpful to allow Thunderbird with the most recent(and most secure) Mozilla platform code. or (b) In order to avoid being broken, accept that Thunderbird might have to fork portions of the Gecko code, in order to remain compatible. But as soon as we go that path, we might soon see Thunderbird having to use a full fork of Gecko and fall behind. I don't think we'd be happy with this scenario.

I therefore propose that we make it a rule that developers must follow strategy (a). If developers want to remove or replace a functionality in core Gecko, they must not do it until someone has contributed a working adjustment to Thunderbird code.

Joshua Cranmer We only have ~50-60% coverage of our own code by unit tests. Most problems won't be found except by people using the product (sadly).

Ludo: Before 17 is relaesed I'd love for us to get to 70%. And yes in fact most of the bugs found since we have automation,have been by users. But what the automation gave us and the enforcement of new tests is way less regressions and a bit more coverage. I'm really happy about about the regression rate we had since we've enforced tests to be added with patches.

Karsten If you move away from Gecko Core, you're doomed, given the number of actual developers working on Thunderbird. Especially since no Gecko person will then care anymore whether something breaks for us or not.

Kai Knowing about a regression is important, but is not sufficient. Even known regressions are sometimes being deliberately ignored (or potential fixing gets postponed to "unknown"). For example, since Thunderbird 10 we have no error feedback for many protocol errors on SSL/TLS connections. If there's a problem with a connection to a server, it simply doesn't work, without user feedback.

Joshua Cranmer If the goal is to move primarily to community innovation, then I think there ought to be an explicit roadmap that lays out the changes that we agree want to be made for Thunderbird, to give contributors guidance as to what would be most useful to work on? I also think it would be useful to have some sort of liaison with the people working on the Gaia email app to explore future possibilities of sharing code.

It also struck me that I forgot to mention that having a Thunderbird<->Gaia email sync ought to be a major goal.

IMAP doesn't share everything. As Ludo mentioned, it doesn't synchronize contacts; there is also the issue of certain types of message annotations not being totally shared (labels, junk status, etc.) or basic settings either.

Bron Gondwana: This is something I'm particularly interested in, as a server maintainer and supposedly working on a "better than IMAP" mail protocol. If there's stuff I can do, or get involved in, I would be very interested in this. One thing I'm doing with Cyrus at the moment is reworking the replication protocol (yet again!) to hopefully allow non-administrator full replication as well - so regular users could run a local Cyrus instance and replicate in a bandwidth efficient way with their ISP server (if it was Cyrus) such that they not only had a 100% exact replica local copy of all the remote server's internal state, but they could make changes offline and synchronise efficiently too.

Joshua Crammer: I was more thinking of some clear two-way communication so that contributors on either product are well aware about potential to avoid code duplication, etc. In particular, I might think that there be some form of "gaia email update" on the TB status meetings and v.v. just so people are well aware. It also struck me that I forgot to mention that having a Thunderbird<->Gaia email sync ought to be a major goal.

eric Moore - The proposal doesn't address several issues such as - who will maintain the ISP database, and what happens to account provisioning (is anybody left authorized to sign contracts with new email providers?). I don't see the need for security patches every six weeks for a email client. People can still safely use 2.0.0.24 if they apply common sense. The security advisories seem to deliberately inflate the impact of potential problems. I'd argue that a new release every 6 weeks actually contributes to stability problems, especially if there is no longer a QA lead. => Mark banner : The ISP database has at least one community member already doing reviews for new entries, I believe the reviews can be done by almost anyone with a knowledge of the APIs, but I'm sure Ben can correct me if I'm wrong.

For the server part of the ISP database, that's within Mozilla. If the GSoC student completes the work on the new ISPDB application, then that could be hosted somewhere and the ISP database run from there. => Ludo: On the long term having isp host the files and knowing about it would be enough that we shouldn't worry about the ispdb. Maybe it should be pushed to the IETF and published like an RFC.

Eric Moore Cont-d: SeaMonkey is a community effort hosted by and under the legal protection of the Mozilla Foundation, with the SeaMonkey Council providing the project leadership. SeaMonkey would seem a better model than maintaining the status quo with a fraction of the existing resources. Most of the Thunderbird module owners seem to be Mozilla employees. Its not clear why that would change anytime soon. I'm worried that the project will continue to pay the political cost of being a Mozilla project (many decisions dictated by what Firefox does or Mozilla's roadmaps) while losing most of its resources. That doesn't seem viable.

It would help if a few features developed over a long time that are near completion such as maildir support were finished and there was some sort of explicit exit criteria to have a smooth handoff rather than development ending as soon as a new governance model was established. That doesn't necessarily require more investment by Mozilla, it might be done by prioritizing what needs to get done before the transition. https://wiki.mozilla.org/Features/Thunderbird

It wouldn't hurt to evaluate removing some half-way finished implementations (such as anti-phishing, which most people disable) that will probably never be finished due to lack of interest in order to make Thunderbird a little easier to maintain.

5. The proposal doesn't mention the impact on SeaMonkey. My impression is they leverage bug fixes and new features developed by Mozilla for Thunderbird, and this means they are going to have to divert some of their limited resources. Some volunteers such as rsx11m seem to work on both projects. Perhaps there needs to be some more explicit coordination to help deal with the common lack of resources.

6. "We have come to the conclusion that continued innovation on Thunderbird is not a priority for Mozilla and that the most critical needs for the product are on-going security and stability. In fact, it is quite possible that Thunderbird is already pretty much what its users want and there is not a high demand for innovation in this field. "

Users want a product that is under active development and has a future, even if they don't really care about the new features or get annoyed by some of the changes. I suspect many users will interpret the re-focusing of efforts as Mozilla abandoning Thunderbird, and will look for alternative email clients since they don't perceive the community as providing enough development. I think there would have been a much better reaction if Mozilla had announced they were reducing staffing levels (there were only two full time employees for a good while) but would continue new development at a slower pace.

Ludo: Yes it would be nice to have and probably have a sort of roadmap so people who want to participate might get ideas on what needs to be worked on.

Karsten: What does this mean? TB won't get _any_ updates to new Gecko versions? Or TB won't get updated to _all_ Gecko versions?

JBPiacentino: This means that Thunderbird and Thunderbird ESR will use Gecko 17, which will be updated for security and stability avery 6 weeks, for the whole 54 weeks ESR cycle duration. Beyond that, we'll switch to ESR 24, and so on..

Joachim Herb: I contributed to some (very) small patches for Thunderbird, e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=519956 It took 6 month to get the patch into Thunderbird. This was already laborious. With the 6-week release cycle there was a chance to see your work included within a reasonable time. Now, if a new version of Thunderbird is only released once a year and a patch misses that opportunity, does it mean you have to wait for another year? This does not sound very motivating.

R Kent: In the thread "Gecko versions for future Thunderbird releases" I discuss some of the possible organization of future releases. Using the terminology from that thread, according to my proposal you would land your patch on comm-central, which is synced to mozilla-central Gecko and would for sure land in the annual TB-next and TB-ESR (and would be available in EarlyBird on the aurora channel prior to that). If the patch does not cause interface changes, nor depend on the Gecko version, then it could be nominated for inclusion in the more frequent TB-Main (with releases perhaps quarterly). That is accomplished by pushing the patch to comm-beta.

I think that is is a reasonable compromise that allows development to keep up with Gecko changes, while allowing more stability in TB-Main.

Hubertus Hilgers : ....For example a comfortable Maildir-Support, and as mentioned by many others too, an update of the directory. ... for excample the support of a Metro-Version also for the future, writing messages should be possible in one tab, combining the two search-borders, implementing an attachement-browser, URL-preview, profil-recovery for damaged profiles, centralizing of all options and features including a search function for options, home tab.... If the developement of Thunderbird will be performed by external contributors, of course some of the improvals might be implemented by them in future, but regarding the Metro-developement... that this development should remain in the hand of Mozilla itself.

Andrew Sutherland (Cyrus collaboration) Although the B2G e-mail app is message-centric for the time being, we will likely go conversation-centric again in the future. During my most recent investigations of modern IMAP servers, I saw that Cyrus is working on explicit support for conversations, possibly as a new standard extension (XCONVERSATIONS?). Because conversations are most problematic for mobile devices that don't want to sync the entire contents of a folder, this is especially interesting for me and B2G email. Probably less so for Thunderbird since only the global database cares about conversations and its desire to work cross-account means it might not benefit so much.

Bron Gondwana ... The one nice thing we could offer (with XCONVERSATIONS) to something like Thunderbird is the "CID" field, which is the same for every message that we have already joined into a conversation on the server. I believe Gmail also exposes a 64 bit value, and both are essentially "random" as far as clients are concerned... so code to deal with one could deal with the other easily enough.

Andrew: The replica work sounds very interesting; does it only support 100% replicas, or does it support subsets? Bron: For now, it's only 100% replica. Subsets in terms of users is pretty easy. Subsets in terms of "not synchronising all the messages in the single folder" is substantially trickier - especially since it uses an XOR of the CRC32 of a representation of every message to create a final "SYNC_CRC" value which can be compared to ensure both ends are identical.

Axel: ... Also, we do need some key persons with available on IRC to nurture the community in their efforts to get involved in the innovation part. I do like the new module governance model though, it might be a good idea to specialize people a little more. For instance, we still need somebody who would like to take over the composer piece, that's in need of new leadership, badly. If we could motivate the more talented members of the community in some way to take this on (e.g. maybe with a specific credits page, like on other high profile software dev efforts such as commercial games) I see a chance that Tb could come out as a better (and not just more stable) product.