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?

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).

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