Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Thunderbird 3 Planning

66 views
Skip to first unread message

David Ascher

unread,
Jan 28, 2008, 5:53:49 PM1/28/08
to
It's time to define the Thunderbird 3 plan. I've spent a fair bit of
time learning about the state of affairs and talking to many people, and
I feel I've accumulated enough information to start this process.

Note: I'm cross-posting this to the planning, calendar and thunderbird
newsgroups, but expect discussion on the thunderbird newsgroup and have
set followup-to accordingly. There will be a summary post in the
planning newsgroup if the final plan differs significantly from the one
outlined here.

The long-term roadmap of Thunderbird is still in flux, but there are
four high-level points which drive my thinking about Thunderbird 3:

1. Thunderbird's impact is proportional to its user count. Thus driving
adoption is my primary concern. Our current user base is very
significant (many millions of mostly quite satisfied users), but the
number of possible users of Thunderbird is orders of magnitude greater
than our current reach.

2. The reasons why people don't choose to use Thunderbird are varied,
but two primary reasons appear to be: the lack of a built-in calendar
integration (compared to Outlook for example), or a search experience
that doesn't match that offered by competitors (gmail and Mail.app for
example).

3. In addition, Thunderbird's codebase has a fair bit of technical debt
due to insufficient resourcing over the years, which has led to a
codebase which has too many scary bits, not enough test coverage, and
isn't yet able to leverage the ongoing platform improvements. In
addition, while communications clients are by nature great targets for
extension authors, the current codebase isn't extension-friendly enough,
making it too hard to build installation-specific features or experiment
with new feature ideas.

4. A fair number of Thunderbird changes have already landed on trunk,
including some important bug fixes, by a variety of contributors.
There's appropriate pressure to ship an update to Thunderbird 2 to take
advantage of those and of the platform improvements.

With all that as background, I propose:

* Goal: to have at public milestone build of Thunderbird 3 in 2008.
Thunderbird 3's overall aim is to significantly grow its user base
worldwide, as well as build a strong foundation for later Thunderbird
releases.

* Release-defining features:
- an integrated calendaring feature, based on Lightning
- a better search experience, especially for message content searches
- a better overall user experience

* Less user-visible but important goals include:
- Significant headway on getting rid of Mork and RDF
- A concerted effort to improving the extensions ecosystem for
Thunderbird, including refactorings, FUEL, developer documentation, and
user experience
- Better test coverage and performance metrics in place to support
refactoring goals

There will be of course lots of other bug fixes and enhancements
(patches welcome ;-))

* Schedule: Figuring out the schedule at this stage is hard, as it will
depend on who shows up with energy and talent. I would like to set some
placeholder milestones for discussion, however:

- alpha builds in Q1
- beta builds without calendaring starting in Q2
- beta builds with calendaring starting in Q3
- widely useful builds by Q4 (although whether they're branded
"release" will depend on quality, as always).

We're revise the schedule as we gain knowledge.

* Thunderbird 3 work will happen on trunk, with branching strategy to be
figured out closer to the endgame (and reviewed next when 1.9 is cut),

* The Mailnews/Thunderbird folks and the Calendar folks will have to
figure out how to best allocate dev and testing effort on the
calendaring features, how we support Sunbird, etc.

Given the scope of the work, the aggressive schedule, and the amount of
new feature develoment, integration and stabilization work involved,
help of all kinds is more than welcome! Thanks in advance for any input
you may have, either on process or on deliverables.

The central wiki page for Thunderbird 3 is
http://wiki.mozilla.org/Thunderbird:Thunderbird3. IRC discussion will
take place in #maildev. The newsgroup/mailing list of record for Tb3 is
mozilla.dev.apps.thunderbird.

I look forward to the discussion!

-- David Ascher

Eddy Nigg (StartCom Ltd.)

unread,
Jan 28, 2008, 6:18:17 PM1/28/08
to David Ascher, dev-pl...@lists.mozilla.org, dev-apps-t...@lists.mozilla.org, dev-apps...@lists.mozilla.org
Hi David,

This plan looks to me overall as modest and doable, with the right set
of priorities to prepare for future and bolder goals and aims. Perhaps
the time line could be squeezed a little bit in order to have a release
in 2008, considering that Lightning has improved quite a bit lately.
However the plan looks realistic and serious to me.

--
Regards

Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber: star...@startcom.org <xmpp:star...@startcom.org>
Blog: Join the Revolution! <http://blog.startcom.org>
Phone: +1.213.341.0390

> _______________________________________________
> dev-apps-thunderbird mailing list
> dev-apps-t...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-thunderbird
>

Sergey Yanovich

unread,
Jan 28, 2008, 6:57:34 PM1/28/08
to
David Ascher wrote:
> With all that as background, I propose:
>
> * Goal: to have at public milestone build of Thunderbird 3 in 2008.
> Thunderbird 3's overall aim is to significantly grow its user base
> worldwide, as well as build a strong foundation for later Thunderbird
> releases.
>
> * Release-defining features:
> - an integrated calendaring feature, based on Lightning
> - a better search experience, especially for message content searches
> - a better overall user experience
>
> * Less user-visible but important goals include:
> - Significant headway on getting rid of Mork and RDF
> - A concerted effort to improving the extensions ecosystem for
> Thunderbird, including refactorings, FUEL, developer documentation, and
> user experience
> - Better test coverage and performance metrics in place to support
> refactoring goals
>
> There will be of course lots of other bug fixes and enhancements
> (patches welcome ;-))

This may also be cool:
* Improved administrator experience:
- MSI;
- Group Policy Options.


There is a thread 'Firefox for Corporations' in m.d.platform, which
fully applies to Thunderbird. Please check bug 231062 for MSI patches :)

--
Sergey Yanovich

Gary Kwong

unread,
Jan 28, 2008, 7:02:19 PM1/28/08
to
> - alpha builds in Q1
> - beta builds without calendaring starting in Q2
> - beta builds with calendaring starting in Q3
> - widely useful builds by Q4 (although whether they're branded "release"
> will depend on quality, as always).

That will also depend on the timeframe that Calendar hits 1.0, though I
think it's projected for 2008 as well.

I'm of the opinion that the first beta should have already included
Lightning if it's one of the main pillars of the Thunderbird 3 release.
What's the point of calling it a beta when one of the main backbone
features is not present?

I am leaning towards the possibility of including Lightning 0.9 in an
Alpha / Beta 1 build, as a form of "dress rehearsal" for 1.0.

>
> * The Mailnews/Thunderbird folks and the Calendar folks will have to
> figure out how to best allocate dev and testing effort on the
> calendaring features, how we support Sunbird, etc.


There's substantial code that overlaps with Lightning, and also there's
code that doesn't. If 100% of Lightning's tested to work fine, chances
are that 60%++ of Sunbird already works well, the other 40% being
non-overlapping stuff. (something to keep in mind for QA)


Gary Kwong

David Ascher

unread,
Jan 28, 2008, 7:05:57 PM1/28/08
to Sergey Yanovich, dev-apps-t...@lists.mozilla.org
Sergey Yanovich wrote:
> This may also be cool:
> * Improved administrator experience:
> - MSI;
> - Group Policy Options.
>
>
> There is a thread 'Firefox for Corporations' in m.d.platform, which
> fully applies to Thunderbird. Please check bug 231062 for MSI patches :
Thanks for the note. I'm certainly interested in figuring out the
various "enterprise" requirements. In addition to MSI and Group Policy
issues, there are update management issues, as well as UI-limiting ideas
like those outlined in bug 414301.

We should discuss this on the community-enterprise list, however -- I'm
still trying to figure out how many sub-communities there are trying to
tackle organizational deployments of Thunderbird, and which of the
requirements are highest priority.

--david

Myk Melez

unread,
Jan 28, 2008, 7:08:37 PM1/28/08
to
David Ascher wrote:
> It's time to define the Thunderbird 3 plan. I've spent a fair bit of
> time learning about the state of affairs and talking to many people, and
> I feel I've accumulated enough information to start this process.

To me this looks like a great plan, appropriately scoped but with real
and significant progress and promise for Thunderbird futures. I second
Eddy's desire for a final release this year, but my reading of your
proposal is that it plans for exactly that outcome, just with a bit of
hedging given the difficulty of making that prediction and the desire
for a quality- rather than merely date-driven release.

-myk

David Ascher

unread,
Jan 28, 2008, 7:19:14 PM1/28/08
to Myk Melez, dev-apps-t...@lists.mozilla.org
Gee, I'm that transparent. ;-)

I'm very keen to see a public release in 2008. But it's a foolish dev
manager who sets scope and schedule with absolutely no visibility on
available resources =)

While adding people to a late project makes it later, having too few
hands on keyboards makes it hard to produce good releases -- there's a
careful balance to be found.

My plan is to focus on getting as many bright people interested in
working on it as soon as possible, and with enough planning, enthusiasm,
luck, and the right discipline regarding scope creep, we may just get
there...

--david

JoeS

unread,
Jan 28, 2008, 8:56:46 PM1/28/08
to

Ah.. regarding quality, might we address the issue of core code changes that affect apps like thunderbird.
Since https://bugzilla.mozilla.org/show_bug.cgi?id=385740 which was a great change for Firefox myk, the trunk
for Tbird was severely impacted. If you save an action, as far as opening a link or calling a helper app, there
is absolutely no way to edit that pref. Apart from saving your mimeTypes.rdf (or a null version of same) you are
stuck with your decision.
These things are constantly cropping up, some serious, some not.
https://bugzilla.mozilla.org/show_bug.cgi?id=413200 has lingered now for a week or so.

-- JoeS


Eddy Nigg (StartCom Ltd.)

unread,
Jan 28, 2008, 9:07:08 PM1/28/08
to JoeS, dev-apps-t...@lists.mozilla.org
JoeS wrote:
> These things are constantly cropping up, some serious, some not.
> https://bugzilla.mozilla.org/show_bug.cgi?id=413200 has lingered now for a week or so.
>
>
Well, a bug with so much activity in one week...I wouldn't call that
"lingering" ;-) I guess your expectations are quite high...

Myk Melez

unread,
Jan 28, 2008, 9:16:22 PM1/28/08
to
JoeS wrote:
> Since https://bugzilla.mozilla.org/show_bug.cgi?id=385740 which was a
> great change for Firefox myk, the trunk
> for Tbird was severely impacted. If you save an action, as far as
> opening a link or calling a helper app, there
> is absolutely no way to edit that pref. Apart from saving your
> mimeTypes.rdf (or a null version of same) you are
> stuck with your decision.

Sorry, I wasn't aware of this regression. It does sound like a problem.
I'll follow up in the bug.

-myk

JoeS

unread,
Jan 28, 2008, 9:17:55 PM1/28/08
to
Eddy Nigg (StartCom Ltd.) wrote:
> JoeS wrote:
>> These things are constantly cropping up, some serious, some not.
>> https://bugzilla.mozilla.org/show_bug.cgi?id=413200 has lingered now
>> for a week or so.
>>
> Well, a bug with so much activity in one week...I wouldn't call that
> "lingering" ;-) I guess your expectations are quite high...
>
That's just a minor bug, but my point is that core bugs that break Tbird don't seem to get the attention that they deserve.
I'll just call that "Firefox centric" development. If we are going to get more nightly testers involved, which I think is
really necessary for the advancement of 3.0 we deserve a little respect (as does tbird itself)
The trunk has been busted for periods of several weeks in the past due to core problems. Not a good incentive for testing.


David Ascher

unread,
Jan 28, 2008, 9:31:24 PM1/28/08
to JoeS, dev-apps-t...@lists.mozilla.org
All of which is why we're starting MailCo, recruiting full-time devs as
well as encouraging volunteer contributors, hiring a build engineer,
promoting test suite development, etc.

Joe - don't hesitate to let me know of specific bugs which need
attention, and I'll see what I can do about raising their profile. I
know for a fact that Myk cares a lot about Thunderbird, and I'm sure
that he respects it plenty =).

--david

Pascal Sartoretti

unread,
Jan 29, 2008, 3:57:11 AM1/29/08
to
David Ascher wrote:
> * Release-defining features:
> - an integrated calendaring feature, based on Lightning
> - a better search experience, especially for message content searches
> - a better overall user experience

I would add RSS to this list of features:

1. Thunderbird has a very basic RSS support, but it is barely usable due
to numerous usability issues (if there were only a few, I would have
created issues in Bugzilla).

2. Thunderbird already wraps together an e-mail client and an NNTP
client. Although some prefer to read RSS feeds in their browser, many
others (including me) think that reading RSS feeds is an activity which
closely resembles reading NNTP newsgroups.

3. The basic infrastructure for an excellent RSS reader is already
present in Thunderbird (HTML viewer, search folders, proxy options, etc...).

4. An excellent RSS reader would also increase the user base, which is a
goal of Thunderbird 3.

Hence, I think that with a reasonable effort Thunderbird could become a
great RSS reader.

Pascal

Arivald

unread,
Jan 29, 2008, 4:40:13 AM1/29/08
to
David Ascher pisze:

My company almost decide to use Exchange. So if we want to have calendar
built-in, then maybe there should support for Exchange features.
Or at least it should be possible to make extension which provide needed
functionality.

--
Arivald

Simon Paquet

unread,
Jan 29, 2008, 6:09:06 AM1/29/08
to
David Ascher wrote on 28. Jan 2008:

> * Goal: to have at public milestone build of Thunderbird 3 in 2008.
> Thunderbird 3's overall aim is to significantly grow its user base
> worldwide, as well as build a strong foundation for later
> Thunderbird releases.
>
> * Release-defining features:
> - an integrated calendaring feature, based on Lightning
> - a better search experience, especially for message content searches
> - a better overall user experience

These sound like fine goals to me.

> * Schedule: Figuring out the schedule at this stage is hard, as it
> will depend on who shows up with energy and talent. I would like
> to set some placeholder milestones for discussion, however:
>
> - alpha builds in Q1
> - beta builds without calendaring starting in Q2
> - beta builds with calendaring starting in Q3

While this sounds great in theory, it has some pretty drastic
implications for Calendar development, which one should be aware of.

| Note: I speak only for myself and from my own experience here. The
| only person who can speak with authority about the Calendar
| project is Daniel Boelzle, our lead developer.

Currently Calendar development happens exclusively on the 1.8 branch
to enable us to fully support TB2. All changes are cross-committed
to the trunk as well, but due to API and other architectural changes
there exist several pretty serious regressions on the trunk that we
know about.

There are probably even more regressions which we don't know about,
because we've told our testers to focus their testing on the 1.8 branch
and only a few are testing trunk builds once in a while.

I'm not a software engineer, but I would expect that it would take us
at least a month to play catchup on the trunk and fix the outstanding
regressions. This would of course mean that our planned feature
implementations for 0.9 and 1.0 would have to be postponed for said
month.

In addition it would increase the work for developers and reviewers,
who right now are not obliged to test their code on the trunk. It
would also mean that we need more manpower in the testing community,
but I'm not very concerned about that, since the inclusion into TB3
nightlies would probably result in a QA manpower increase.

> * The Mailnews/Thunderbird folks and the Calendar folks will have
> to figure out how to best allocate dev and testing effort on the
> calendaring features, how we support Sunbird, etc.

We'll have to think long and hard about what we'll do with Sunbird.
We'll also have to think whether we want to support SeaMonkey and how
much we want to support it, given that those guys will most likely
release alpha or beta releases of SM2 during that timeframe as well.

Simon

--
Calendar l10n coordinator
Calendar Website Maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog: http://weblogs.mozillazine.org/calendar

Pascal Sartoretti

unread,
Jan 29, 2008, 8:04:02 AM1/29/08
to
David Ascher wrote:
> I'm certainly interested in figuring out the various "enterprise" requirements.

Full Exchange support would be nice :-)

More seriously, I think that one single feature would greatly help the
use of Thunderbird in Exchange-based companies: the ability to *answer*
to meeting requests (currently, Thunderbird simply *displays* meeting
requests).

Pascal

Simon Paquet

unread,
Jan 29, 2008, 8:52:53 AM1/29/08
to

This is already possible if you install the Lightning extension.

Pascal Sartoretti

unread,
Jan 29, 2008, 9:15:03 AM1/29/08
to
Simon Paquet wrote:
>> More seriously, I think that one single feature would greatly help the
>> use of Thunderbird in Exchange-based companies: the ability to
>> *answer* to meeting requests (currently, Thunderbird simply *displays*
>> meeting requests).
>
> This is already possible if you install the Lightning extension.

Ooops, you're right, Lightning now supports it. However, the message it
sends back to the meeting requester is a simple text message, no a
(proprietary) Exchange acknowledgment. Hence, the meeting request in the
requester's calendar will not be updated, and the requester will notice
that I am a "second class citizen" in term of Exchange integration.

Anyway, Lightning is getting better, congratulations!

Pascal

Robert Kaiser

unread,
Jan 29, 2008, 9:21:23 AM1/29/08
to
Pascal Sartoretti wrote:
> 1. Thunderbird has a very basic RSS support, but it is barely usable due
> to numerous usability issues (if there were only a few, I would have
> created issues in Bugzilla).

You should still file bugs, no matter how many or how big the issues are.

Robert Kaiser

Robert Kaiser

unread,
Jan 29, 2008, 9:28:07 AM1/29/08
to
Simon Paquet wrote:
> Currently Calendar development happens exclusively on the 1.8 branch
> to enable us to fully support TB2. All changes are cross-committed
> to the trunk as well, but due to API and other architectural changes
> there exist several pretty serious regressions on the trunk that we
> know about.

Maybe the time is arriving where that cross-commit policy needs to be
lifted (I know, that's also a question of manpower).

> We'll have to think long and hard about what we'll do with Sunbird.

True. Unfortunately the case is not as simple as with e.g. ChatZilla
here, which is able to run both as an extension and as a XULRunner app
with practically the same code - Lightning not being run in its own
window complicates things there.

> We'll also have to think whether we want to support SeaMonkey and how
> much we want to support it, given that those guys will most likely
> release alpha or beta releases of SM2 during that timeframe as well.

Yes, SeaMonkey surely will do Alphas and Betas, hopefully even a final
release of SeaMonkey 2 in that timeframe. We do not plan to ship with
Lightning in this cycle (yet), but it would be nice if we get it to run
in SeaMonkey, part of which can be achieved through making SeaMonkey
MailNews more similar to Thunderbird, but other parts might need some
patches in Lightning as well.

Robert Kaiser

Robert Kaiser

unread,
Jan 29, 2008, 9:32:05 AM1/29/08
to
David Ascher wrote:
> * Less user-visible but important goals include:

The change from wallet to toolkit's LoginManager should be added here.
Mark Banner has done some work for that, see
https://bugzilla.mozilla.org/show_bug.cgi?id=239131 and its dependencies.

Robert Kaiser

SanderG

unread,
Jan 29, 2008, 10:19:53 AM1/29/08
to
On Mon, 28 Jan 2008 14:53:49 -0800, David Ascher wrote:

David,

Thanks for sharing the planning. Imho it's a good starting point for
discussion.

Personally I think the points you mention are very good. There are also
some other points I hear from users around me that would help user
adoption, such as:

- Corporate users:

1. Sync the calendar with Exchange, without needing Outlook. Use OWA or a
provider to sync with the Exchange calendar;

2. Ease the install and maintainability of the software. Installing
updates is a pain, and sometimes users manage to download an update and
are unable to apply it, after which it sticks in their profile until
someone pinches it out with a needle;

- Home users:
Integration with e.g. the Windows Address Book (read and write), Gmail
IMAP (including the Google recommended changes to the Thunderbird
settings for cache and attachment fetching, saving sent messages etc.)

What I would also appreciate is more external address book functionality
- store it on Mozilla servers (Weave?), LDAP server support including
ldap-write, Google account address book or something like that, so users
with multiple accounts can sync their address book and share it with
their family.

The most important one would be Exchange calendar sync. If that cannot be
done very soon it might still be worthwhile to _mention_ it so people
know that it's on the radar.

Regards
Sander

Simon Paquet

unread,
Jan 29, 2008, 10:20:50 AM1/29/08
to
Robert Kaiser wrote on 29. Jan 2008:

>> Currently Calendar development happens exclusively on the 1.8
>> branch to enable us to fully support TB2. All changes are
>> cross-committed to the trunk as well, but due to API and other
>> architectural changes there exist several pretty serious
>> regressions on the trunk that we know about.
>
> Maybe the time is arriving where that cross-commit policy needs
> to be lifted (I know, that's also a question of manpower).

I don't understand this. What do you mean with lift the cross-commit
policy of mozilla/calendar?

We can't just switch to the trunk. We have a few hundred thousand users
on TB2 and we can't just let them hang out in the open while TB3 is
still in alpha, beta or RC stage.

So at least until Lightning 1.0 is released (probably even longer) we
will stay on the branch or at least commit a major part of our
development resources there.

Pascal Sartoretti

unread,
Jan 29, 2008, 10:21:32 AM1/29/08
to
Robert Kaiser wrote:
> You should still file bugs, no matter how many or how big the issues are.

Here is what I think about RSS support in Thunderbird: the whole
configuration UI is a mess, I am confused between what is a feed, a
subscription, a location and a folder (from a user point of view, they
are pretty much all the same...).

I don't know how to express this in a constructive way in Bugzilla :-)

On the other hand, the UI for reading RSS is ok.

Just a question to Thunderbird users: who also uses it for RSS?

Pascal

Simon Paquet

unread,
Jan 29, 2008, 10:30:50 AM1/29/08
to
SanderG wrote on 29. Jan 2008:

> Thanks for sharing the planning. Imho it's a good starting point for
> discussion.
>
> Personally I think the points you mention are very good. There are
> also some other points I hear from users around me that would help
> user adoption, such as:
>
> - Corporate users:
>
> 1. Sync the calendar with Exchange, without needing Outlook. Use OWA
> or a provider to sync with the Exchange calendar;

Exchange support would be great to have of course, but it is
absolutely impossible to achieve this in the TB3 timeframe that David
proposed.

In addition the only viable open source solution that could be used
to quickly add Exchange support to Thunderbird and Lightning (libmapi)
can not be used because of license imcompatibilities (libmapi uses
GPLv3, while we use the MPL/LGPL/GPL tri-license).

Unless the libmapi developers change their license, we would have to
implement this stuff from scratch, which would probably take at least
1-2 years to reach a "basic support"-milestone.

Peter Lairo

unread,
Jan 29, 2008, 10:44:52 AM1/29/08
to
Pascal Sartoretti on 29.01.2008 09:57 wrote:
> David Ascher wrote:
>> * Release-defining features:
>
> I would add RSS to this list

I disagree that RSS is important to Thunderbird. Reading RSS in a
three-pane e-mail program is painful because the articles are set up
like web pages (i.e. vertically long) and having to read them in *half
the vertical space* of the Thunderbird window (the message pane)
severely limits the needed vertical space. Also, RSS feeds are basically
*web pages* and thus have more to do with a browser than an e-mail program.

I would much rather see Thunderbird's very limited resources be used on
(IMO more important) things like:

Improving the chi-square spam detection method
https://bugzilla.mozilla.org/show_bug.cgi?id=243430

Ignore (kill) a Subthread (branch: not the whole thread)
https://bugzilla.mozilla.org/show_bug.cgi?id=11054

Define official Mozilla LDAP schema extension
https://bugzilla.mozilla.org/show_bug.cgi?id=116692

XP way to show number in current locale (with correct decimal and
thousands separators) needed
https://bugzilla.mozilla.org/show_bug.cgi?id=108689

Add birthday fields to address book
https://bugzilla.mozilla.org/show_bug.cgi?id=13595

ship with a pre-populated training.dat file?
https://bugzilla.mozilla.org/show_bug.cgi?id=179999

Hide/Mute quoted text
https://bugzilla.mozilla.org/show_bug.cgi?id=35929

Use a SQLite Database for Storing Mails
https://bugzilla.mozilla.org/show_bug.cgi?id=361807

requesting conversion from mork db to sqlite for addressbooks
https://bugzilla.mozilla.org/show_bug.cgi?id=382876

<blockquote type="cite"> is nonstandard
https://bugzilla.mozilla.org/show_bug.cgi?id=183219

[Tracking] Critical roaming bugs
https://bugzilla.mozilla.org/show_bug.cgi?id=228629

Roaming for Thunderbird (synchronize, synchronization)
https://bugzilla.mozilla.org/show_bug.cgi?id=310158

Dragging email over closed folder doesn't open (expand) sub folders
https://bugzilla.mozilla.org/show_bug.cgi?id=338401

Ability to select from multiple signatures (global / per account?)
https://bugzilla.mozilla.org/show_bug.cgi?id=73567

put signature editing in UI (rather than select a file)
https://bugzilla.mozilla.org/show_bug.cgi?id=324495

Would like to see a space between number and "kB" in message size
https://bugzilla.mozilla.org/show_bug.cgi?id=302143

Need: View -> Messages -> Watched Thread (ALL, not just "Unread")
https://bugzilla.mozilla.org/show_bug.cgi?id=294901

Turn off Extra Send Progress Window by Default
https://bugzilla.mozilla.org/show_bug.cgi?id=218557

RFE: "Compact" or "Purge" button
https://bugzilla.mozilla.org/show_bug.cgi?id=75927

Many of these bugs already have code that needs to be checked-in or are
trivial to fix. Others are very difficult but also very important.

BTW: I would also prefer if Firefox improved its nearly unusable RSS
feeder - ideally by integrating the lean and only truly usable *Sage*
Add-on.
https://addons.mozilla.org/en-US/firefox/addon/77?id=77
--
Regards,

Peter Lairo

The browser you can trust: http://www.GetFirefox.com
Reclaim Your Inbox: http://www.GetThunderbird.com

Pascal Sartoretti

unread,
Jan 29, 2008, 12:00:35 PM1/29/08
to
Peter Lairo wrote:
> I disagree that RSS is important to Thunderbird. Reading RSS in a
> three-pane e-mail program is painful

A matter of taste (and monitor size).

RSS support should either be improved or suppressed.

Mark Banner

unread,
Jan 29, 2008, 12:25:36 PM1/29/08
to
Simon Paquet wrote:
> I'm not a software engineer, but I would expect that it would take us
> at least a month to play catchup on the trunk and fix the outstanding
> regressions. This would of course mean that our planned feature
> implementations for 0.9 and 1.0 would have to be postponed for said
> month.

I understand the impact on the future releases, but what is your current
timescale for them (I couldn't see after a quick look on the calendar wiki)?

What I'm thinking, is that how close are 1.0 and TB3 likely to be? Do
you really want to be releasing a 1.0 that doesn't work with TB3 which
is going to be out just around the corner?

Not only that, if they are close enough why not just release them at the
same time?

I can understand the reluctance, but I can also see some advantages to
bringing lightning up to spec on trunk.

Standard8

ovidiu

unread,
Jan 29, 2008, 12:36:55 PM1/29/08
to
More or less answering that:
I kinda use it for reading RSS. Though, I should probably say I use
it, not necessarily for reading as for the backup,offline, markup it
allows. But this goes only for couple of news and blogs that are very
important or that I contribute. Not very usefull, though, as changes in
those posts or other things are not there. But finally, I have to say
that I probably just play with it cause is there and was curious and is
in the same place/sistem as the mail. Could live without..
I would really use it (more) if for there would be tools to allow a
more convenient following or contributing. This means that I can usually
have those RSS as mails too, and not much of a difference. While, if I
could see them along with comments (threaded) and being able to comment,
post, edit etc those, it would be a real tool [as for the UI, that's
another story..]. Till then, there should simply be more media readable
here to make it work (vlogs, posts embeding vids etc..)
On the other hand, my impression is that standards and procedures
concerning this area are not so stable and final and thus, the web may
be a simple answer. I cannot tell how important is this among
features/areas for TB. While a blogging tool (as I describe in the
second..) is already a completly different thing.

Norbert Püschel

unread,
Jan 29, 2008, 12:40:56 PM1/29/08
to
David Ascher schrieb:

> It's time to define the Thunderbird 3 plan. I've spent a fair bit of
> time learning about the state of affairs and talking to many people, and
> I feel I've accumulated enough information to start this process.
>
> With all that as background, I propose:

>
> * Goal: to have at public milestone build of Thunderbird 3 in 2008.
> Thunderbird 3's overall aim is to significantly grow its user base
> worldwide, as well as build a strong foundation for later Thunderbird
> releases.
>
> * Release-defining features:
> - an integrated calendaring feature, based on Lightning

In other words, wouldn't that effectively terminate Lightning as an
independant project? I don't like this. Lightning is IMHO not developed
enough to be chained to Thunderbird in it's release cycle. But better
someone of the Lightning development team say something about this.


> - a better search experience, especially for message content searches
> - a better overall user experience
>

> * Less user-visible but important goals include:

> - Significant headway on getting rid of Mork and RDF

What is more important than killing Mork is IMHO making the address book
extensible and adding a useful synchronisation interface to it. I'm sick
of programs like iTunes that only sync to Outlook. Writing addressbook
synchronisation is quite complicated with Thunderbird 2...

Norbert Püschel

ovidiu

unread,
Jan 29, 2008, 12:49:39 PM1/29/08
to
It is always a matter of what you are looking for. If i.e. TB would
move towards a more 'organizing' thing including those rss, could be
another case. A previous discussion here, regarding AB as fundament for
communication and pim, may show TB as support (eventually) for a more
complex relationship between different tipes of data/links where rss
would fit among some data. Another direction could be to serve those
that contribute to rss and other directions may arrise. Aniway,
improving rss is one thing, while others may be a priority.

Chris Ilias

unread,
Jan 29, 2008, 12:52:00 PM1/29/08
to
On 1/28/08 5:53 PM, _David Ascher_ spoke thusly:

> * Release-defining features:
> - an integrated calendaring feature, based on Lightning
> - a better search experience, especially for message content searches
> - a better overall user experience
>
> * Less user-visible but important goals include:
> - Significant headway on getting rid of Mork and RDF
> - A concerted effort to improving the extensions ecosystem for
> Thunderbird, including refactorings, FUEL, developer documentation, and
> user experience
> - Better test coverage and performance metrics in place to support
> refactoring goals
>
> There will be of course lots of other bug fixes and enhancements
> (patches welcome ;-))

Is it too late to recommend items for the PRD?
Things I think would make Thunderbird rock:

_Account setup library_
Personally, I'd like to see an extensive library of account setup files.
<http://developer.mozilla.org/en/docs/Thunderbird_ISP_hooks>
No Thunderbird user should ever have to type in the server name, port
number, when setting up an account.

_Add-ons browser_
One of Firefox's biggest advantages over the competition is the add-ons
functionality. Thunderbird has it as well, and there are plenty of
extensions to satisfy people's complaints about Thunderbird; but
finding/installing add-ons for Thunderbird is much less user-friendly.
Users should have to "Save link as" from AMO, then use Thunderbird to
open the file. Many users either mistakingly install Thunderbird add-ons
in Firefox, or double-click on the XPI after having downloaded it. The
add-ons browsing experience should take place within Thunderbird. You
can even use this to browse account setup files.


Some other frequent items in the support newsgroup:
- profile backup/restore feature
- webmail support (Hotmail, Yahoo!, etc.)
- newsgroup binary combine and decode
- account re-ordering

> * Schedule: Figuring out the schedule at this stage is hard, as it will
> depend on who shows up with energy and talent. I would like to set some
> placeholder milestones for discussion, however:
>
> - alpha builds in Q1
> - beta builds without calendaring starting in Q2
> - beta builds with calendaring starting in Q3

> - widely useful builds by Q4 (although whether they're branded "release"
> will depend on quality, as always).
>
> We're revise the schedule as we gain knowledge.

I hope the eagerness to get something out the door within the year won't
hurt the quality of the release. (e.g. Netscape 6)

--
Chris Ilias <http://ilias.ca>
List-owner: support-firefox, support-thunderbird, test-multimedia

Simon Paquet

unread,
Jan 29, 2008, 12:58:39 PM1/29/08
to
Mark Banner wrote on 29. Jan 2008:

>> I'm not a software engineer, but I would expect that it would take
>> us at least a month to play catchup on the trunk and fix the
>> outstanding regressions. This would of course mean that our planned
>> feature implementations for 0.9 and 1.0 would have to be postponed
>> for said month.
>
> I understand the impact on the future releases, but what is your
> current timescale for them (I couldn't see after a quick look on
> the calendar wiki)?

Our current plan (AFAIK, I'm not the one making the decisions) was
that we would release 1.0 somewhere in October or November 2008 and
move to the trunk afterwards.

> What I'm thinking, is that how close are 1.0 and TB3 likely to be?
> Do you really want to be releasing a 1.0 that doesn't work with TB3
> which is going to be out just around the corner?

I was not saying that we did not want to release a 1.0 that does not
work with TB3. I was just saying that making that possible has
consequences with regards to when we can push out our next releases.

If it was just about aligning our releases with Thunderbird, I'm sure
we could accomodate, but we'll also have to look at what Sun wants to
do with OpenOffice 3.0 (Sun funds roughly 60% of our devs) and whether
they want OO 3.0 with Thunderbird plus Lightning (see
http://slashdot.org/article.pl?sid=07/10/14/1248233).

> Not only that, if they are close enough why not just release them
> at the same time?
>
> I can understand the reluctance, but I can also see some advantages
> to bringing lightning up to spec on trunk.

We are not reluctant per se, it just means more work for developers
and testers to work in parallel on branch and trunk. And more work
means less fixes in a given timeframe, which results in a longer
preparation time for a release if we assume a fixed developer headcount.

Mark Banner

unread,
Jan 29, 2008, 1:02:25 PM1/29/08
to
Norbert Püschel wrote:
> What is more important than killing Mork is IMHO making the address book
> extensible and adding a useful synchronisation interface to it. I'm sick
> of programs like iTunes that only sync to Outlook. Writing addressbook
> synchronisation is quite complicated with Thunderbird 2...

Although it hasn't branched out here yet, we are looking at making the
address book more extensible and improving its API at the same time as
looking at killing Mork.

Admittedly synchronisation is still one thing I need to look at on the
API front, but we are thinking about it.

Standard8

Mark Banner

unread,
Jan 29, 2008, 1:04:51 PM1/29/08
to
Chris Ilias wrote:
> _Account setup library_
> Personally, I'd like to see an extensive library of account setup files.
> <http://developer.mozilla.org/en/docs/Thunderbird_ISP_hooks>
> No Thunderbird user should ever have to type in the server name, port
> number, when setting up an account.

I disagree with that. Unless you want to provide a constantly updated
list of all the ISPs available to users across the world.

I would much rather we start encouraging ISPs to provide "easy"
configuration extensions that users can just download and install as needed.

Standard8

Simon Paquet

unread,
Jan 29, 2008, 1:08:24 PM1/29/08
to
Norbert Püschel wrote on 29. Jan 2008:

>> * Release-defining features:
>> - an integrated calendaring feature, based on Lightning
>
> In other words, wouldn't that effectively terminate Lightning as

> an independent project? I don't like this. Lightning is IMHO not

> developed enough to be chained to Thunderbird in it's release
> cycle. But better someone of the Lightning development team say
> something about this.

There are a few answers to this:

- Yes, in its current state Lightning is not ready for TB inclusion.
We hope to have it ready when we reach 1.0
- The release cycles of Lightning and TB differ significantly at the
moment. TB will probably only push out one major release every
12-18 months, while Lightning is currently being updated every
4 months
- We could still release updates of Lightning if Lightning would still
be treated as an extension internally and major TB releases could
contain an update.rdf file pointing to addons.mozilla.org where we
would release updates to Lightning

Message has been deleted

ovidiu

unread,
Jan 29, 2008, 2:42:32 PM1/29/08
to
David Ascher wrote:
> It's time to define the Thunderbird 3 plan. I've spent a fair bit of
> time learning about the state of affairs and talking to many people,
> and I feel I've accumulated enough information to start this process.
>
> Note: I'm cross-posting this to the planning, calendar and thunderbird
> newsgroups, but expect discussion on the thunderbird newsgroup and
> have set followup-to accordingly. There will be a summary post in the
> planning newsgroup if the final plan differs significantly from the
> one outlined here.
>
> The long-term roadmap of Thunderbird is still in flux, but there are
> four high-level points which drive my thinking about Thunderbird 3:
>
> 1. Thunderbird's impact is proportional to its user count. Thus
> driving adoption is my primary concern. Our current user base is very
> significant (many millions of mostly quite satisfied users), but the
> number of possible users of Thunderbird is orders of magnitude greater
> than our current reach.
>
> 2. The reasons why people don't choose to use Thunderbird are varied,
> but two primary reasons appear to be: the lack of a built-in calendar
> integration (compared to Outlook for example), or a search experience
> that doesn't match that offered by competitors (gmail and Mail.app for
> example).
>
> 3. In addition, Thunderbird's codebase has a fair bit of technical
> debt due to insufficient resourcing over the years, which has led to a
> codebase which has too many scary bits, not enough test coverage, and
> isn't yet able to leverage the ongoing platform improvements. In
> addition, while communications clients are by nature great targets for
> extension authors, the current codebase isn't extension-friendly
> enough, making it too hard to build installation-specific features or
> experiment with new feature ideas.
>
> 4. A fair number of Thunderbird changes have already landed on trunk,
> including some important bug fixes, by a variety of contributors.
> There's appropriate pressure to ship an update to Thunderbird 2 to
> take advantage of those and of the platform improvements.

>
> With all that as background, I propose:
>
> * Goal: to have at public milestone build of Thunderbird 3 in 2008.
> Thunderbird 3's overall aim is to significantly grow its user base
> worldwide, as well as build a strong foundation for later Thunderbird
> releases.
>
> * Release-defining features:
> - an integrated calendaring feature, based on Lightning
> - a better search experience, especially for message content searches
> - a better overall user experience
>
> * Less user-visible but important goals include:
> - Significant headway on getting rid of Mork and RDF
> - A concerted effort to improving the extensions ecosystem for
> Thunderbird, including refactorings, FUEL, developer documentation,
> and user experience
> - Better test coverage and performance metrics in place to support
> refactoring goals
>
> There will be of course lots of other bug fixes and enhancements
> (patches welcome ;-))
>
> * Schedule: Figuring out the schedule at this stage is hard, as it
> will depend on who shows up with energy and talent. I would like to
> set some placeholder milestones for discussion, however:
>
> - alpha builds in Q1
> - beta builds without calendaring starting in Q2
> - beta builds with calendaring starting in Q3
> - widely useful builds by Q4 (although whether they're branded
> "release" will depend on quality, as always).
>
> We're revise the schedule as we gain knowledge.
>
> * Thunderbird 3 work will happen on trunk, with branching strategy to
> be figured out closer to the endgame (and reviewed next when 1.9 is cut),

>
> * The Mailnews/Thunderbird folks and the Calendar folks will have to
> figure out how to best allocate dev and testing effort on the
> calendaring features, how we support Sunbird, etc.
>
> Given the scope of the work, the aggressive schedule, and the amount
> of new feature develoment, integration and stabilization work
> involved, help of all kinds is more than welcome! Thanks in advance
> for any input you may have, either on process or on deliverables.
>
> The central wiki page for Thunderbird 3 is
> http://wiki.mozilla.org/Thunderbird:Thunderbird3. IRC discussion will
> take place in #maildev. The newsgroup/mailing list of record for Tb3
> is mozilla.dev.apps.thunderbird.
>
> I look forward to the discussion!
>
> -- David Ascher
What about the documentation,(+ help, support and tutorial, along with
'built in usability helpers' (I'll detail that)) for the next release or
generally in TB area?

I do emphasize on the documentation and help cause I strongly think that
if more users to come, the harder it will be to manage that, and a
disappointment (motivated or not) regarding the usage/miss usage of the
app may lead to undesired effects (break enthusiasm..). Obviously, I
consider the documentation, help and generally information for the user,
subject to a growing entropic phenomenon (read a spreading mess) witch
at least needs consolidation and updating, if not a rethink. This is
very much related to the perception of the app in terms of safety and
even maturity from the standard user.

[ I understand that it can be a separate or parallel process, the
rethinking of the user doc and help. But it is somehow a parallel one
also in terms of HR and tasks, enough to be less of a problem to the
people/processes listed above. I mean, should not necessarily put more
stress directly on the aggressive schedule.
Also it may fall under the 'a better overall user experience', but
is somehow a very important thing to consider in terms of the first 'get
more users' idea. Also there may be some things worth being built in, or
things to consider as helpers along the way, like those today that are
from 'alt text' to 'wizards' and somewhere in between the very things
that visually indicate what they do. For such 'built in and usability
helpers' may be the essence of designing the product..]

Anyway, the question is, again, where is the place of 'user
documentation works' (to make it short)?

Gary Kwong

unread,
Jan 29, 2008, 2:51:24 PM1/29/08
to

>
> I was not saying that we did not want to release a 1.0 that does not
> work with TB3. I was just saying that making that possible has
> consequences with regards to when we can push out our next releases.
>
> If it was just about aligning our releases with Thunderbird, I'm sure
> we could accomodate, but we'll also have to look at what Sun wants to
> do with OpenOffice 3.0 (Sun funds roughly 60% of our devs) and whether
> they want OO 3.0 with Thunderbird plus Lightning (see
> http://slashdot.org/article.pl?sid=07/10/14/1248233).

There should soon be discussions between the Thunderbird dev team
(MailCo) and Calendar dev team to discuss this.

Given time, I'm sure something can be worked out.

Gary

Daniel Boelzle

unread,
Jan 29, 2008, 2:53:06 PM1/29/08
to David Ascher, dev-apps-t...@lists.mozilla.org
Hi,

I am quite excited about David's plans incorporating a calendar facility
into Thunderbird 3; it's a great opportunity to actually get a growing
user base!

Wearing my calendar glasses, there are of course quite a couple of
topics that need attention and some have already been mentioned, like
* branch vs. trunk, when is the right time to move over?
=> I don't think we could reliably manage both branches, and I'd opt
for a reasonable move to trunk/1.9 once the TB3 codeline has settled. I
think it's too early to nail that down to a specific calendar release
0.9 or 1.0.
* deployment: will lightning still come as a (preinstalled) extension?
=> IMO this heavily depends on how calendar will evolve in the future
(feature like) and how mature it'll be (w.r.t. quality). My *current*
view on things is that I'd vote to keep it as an extension, being able
to deliver new features and necessary bugfixes frequently.
* What about Sunbird?
=> I expect little changes: we should head for feature parity if
possible, but we have to face that focus will likely move even more to
lightning, because of it's growing user base.

regards,
Daniel

> _______________________________________________
> dev-apps-calendar mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-calendar

Daniel Boelzle

unread,
Jan 29, 2008, 2:54:29 PM1/29/08
to Simon Paquet, dev-apps-t...@lists.mozilla.org
Simon Paquet wrote:
> In addition the only viable open source solution that could be used
> to quickly add Exchange support to Thunderbird and Lightning (libmapi)
> can not be used because of license imcompatibilities (libmapi uses
> GPLv3, while we use the MPL/LGPL/GPL tri-license).
>
> Unless the libmapi developers change their license, we would have to
> implement this stuff from scratch, which would probably take at least
> 1-2 years to reach a "basic support"-milestone.
AFAIK porting libmapi is not that easy, because it's coupled to the
samba libs. While that works for *nix, it's not trivial for Windows.
Incorporating 3rd party libraries are always a pain, so this needs to be
carefully considered. We could always opt for an extension based
solution, of course (instead of adding such code to cvs.mozilla.org).

regards,
Daniel

David Ascher

unread,
Jan 29, 2008, 2:59:34 PM1/29/08
to ovidiu, dev-apps-t...@lists.mozilla.org
ovidiu wrote:
> What about the documentation,(+ help, support and tutorial, along with
> 'built in usability helpers' (I'll detail that)) for the next release or
> generally in TB area?
>

Absolutely, documentation, for users, for extension authors, and for
developers, is an area needing attention -- luckily, apart for API
specific information and things like FUEL, much of it can happen
independently of the release process.

> Anyway, the question is, again, where is the place of 'user
> documentation works' (to make it short)?
>

I'm still gathering information about what the state of user
documentation is, where the best resources are, how to best coordinate
with the work of the Mozillazine community (and equivalents throughout
the world), SUMO, etc. I would appreciate it if someone could put
together a summary of the state of user docs for Tb on a wiki page
somewhere, that'd save me considerable time.

--david

David Ascher

unread,
Jan 29, 2008, 3:11:40 PM1/29/08
to Daniel Boelzle, dev-apps-t...@lists.mozilla.org
Daniel Boelzle wrote:
> Wearing my calendar glasses, there are of course quite a couple of
> topics that need attention and some have already been mentioned, like
> * branch vs. trunk, when is the right time to move over?
> => I don't think we could reliably manage both branches, and I'd opt
> for a reasonable move to trunk/1.9 once the TB3 codeline has settled. I
> think it's too early to nail that down to a specific calendar release
> 0.9 or 1.0.
> * deployment: will lightning still come as a (preinstalled) extension?
> => IMO this heavily depends on how calendar will evolve in the future
> (feature like) and how mature it'll be (w.r.t. quality). My *current*
> view on things is that I'd vote to keep it as an extension, being able
> to deliver new features and necessary bugfixes frequently.
> * What about Sunbird?
> => I expect little changes: we should head for feature parity if
> possible, but we have to face that focus will likely move even more to
> lightning, because of it's growing user base.
>

Agree with all the above. We need to somehow balance the needs of
Sunbird users, Thunderbird 2 + Lightning users; Thunderbird 3 users;
Seamonkey users; developers (both calendar-focused and mailnews
focused); testers of all of the above; localizers of all of the above;
documentation authors for all of the above; and likely more I'm forgetting.

I'm intrigued by the idea of keeping Lightning as a bundled preinstalled
extension. It could allow for interesting upgrade paths down the line,
and I'd guess anything else would make it quite tricky to manage both
1.8 and trunk work. It may be the right incremental step, at least
until there are compelling arguments to do a "deeper" integration, which
I suspect won't come out until we have a clearer picture of the
differences between the Tb3 UX and the Tb2+Lightning UX.

--david

David Ascher

unread,
Jan 29, 2008, 3:27:54 PM1/29/08
to Jay Garcia, dev-apps-t...@lists.mozilla.org
Jay Garcia wrote:
>
> Although Chris didn't specify, I believe he means exactly that, the ISP
> provides the extension already configured. Easy enough to do being an
> ISP myself. An RDF file with a million ISP listings is a bit out of the
> realm of reason. ;-)
>

However, I do like the idea outlined in
http://wiki.mozilla.org/Thunderbird:Easy_Account_Setup#Hosted_Web_Service

--david

Mark Banner

unread,
Jan 29, 2008, 3:39:14 PM1/29/08
to
David Ascher wrote:
> I'm intrigued by the idea of keeping Lightning as a bundled preinstalled
> extension. It could allow for interesting upgrade paths down the line,
> and I'd guess anything else would make it quite tricky to manage both
> 1.8 and trunk work. It may be the right incremental step, at least until
> there are compelling arguments to do a "deeper" integration, which I
> suspect won't come out until we have a clearer picture of the
> differences between the Tb3 UX and the Tb2+Lightning UX.

Just picking up on this, now that SeaMonkey has the new add-on manager,
it will still be shipping some extensions (Inspector, Chatzilla,
JavaScript Debugger - aka venkman) pre-installed as extensions.

For the installer builds there will be an option to disable the
installation of the various extensions.

Some of this has already been tested. Its worth noting that updates to
extensions will be installed in the user's profile (due to admin
privileges etc), whereas the pre-installed extensions will be global.
There's possibly some bugs there, but we believe the general idea is
do-able.

Standard8

mozil...@zindus.com

unread,
Jan 29, 2008, 3:43:28 PM1/29/08
to Norbert Püschel, dev-apps-t...@lists.mozilla.org
Norbert Püschel wrote:
> What is more important than killing Mork is IMHO making the address book
> extensible and adding a useful synchronisation interface to it.

Some ideas around better support for sync in the addressbook:
- change detection
- stable identifiers for content
- distinguishing content and meta-data updates
- rationalising mailing lists

And independent of whether the AB uses Mork, it would be good to have a
decent datastore for sync-related meta-data (sqllite?).

Leni.

David Ascher

unread,
Jan 29, 2008, 4:48:12 PM1/29/08
to dev-apps-t...@lists.mozilla.org
I really value all of these suggested features & bug fixes, but I worry
that just posting them here is likely to get them lost. If you'd like
to have features considered for Tb3, I suggest that the usual process be
followed:

1) file enhancement requests (or find existing ones) in bugzilla

2) Until we figure out a flag policy for tb3, add a pointer to each bug to:

http://wiki.mozilla.org/Thunderbird:Thunderbird_3_Possible_Bugs

or

http://wiki.mozilla.org/Thunderbird:Thunderbird_3_Possible_Enhancements

depending on whether they're bugs w/ existing functionality or enhancements.

More broad points (like the point about documentation and data
migration), which don't fit so neatly in bugs but are more
consciousness-raising arguments, make more sense on the discussion forum
IMO.

--david

ovidiu

unread,
Jan 29, 2008, 4:50:58 PM1/29/08