From MozillaWiki
Jump to: navigation, search

last meeting | index | next week »

Thunderbird Meeting Details


  • Who's taking minutes?
    • asuth

Action Items

Open (going in to the meeting)

  • dmose to do clarifying post about how TB 3.0 roadmap should work w.r.t feature freeze, string freeze, etc.

Open (post-meeting)

  • dmose: clarifying post about how TB 3.0 roadmap should work w.r.t feature freeze, string freeze, etc.
  • davida: Shredder Alpha 2 release notes bug
  • wsmwk: post to the l10n community about testing alpha2 builds for which there are l10n builds available.
  • dmose: Create flags/searches for beta 2.
  • sipaq: file a bug on getting a thunderbird aggregator going on
  • unknown: file a bug on getting a


Thunderbird:Shredder a2

  • All blockers believed fixed.
  • 3.0a2 Tracking Doc
  • RC builds complete, waiting on website and QA activities.
  • davida has release notes bug

Discussion from meeting:

  • question for QA - what is the plan?
  • wsmwk: focus on testing all three platforms. for BFT, to get full coverage, going to parcel out the tests by last name. piece it out in roughly 4 pieces, give half the alphabet to those pieces, and the other 2 pieces. the 2 pieces being one easy set and one harder set.
  • wsmkwk: there are l10 builds out there. people can test l10 builds and e-mail whether they work or not, but not focus on them.
  • davida: might help to get the l10 team involved. seth bindernagel, simon paquet. simon is going to take on the localization coordination for thunderbird. make sure the tool-chain/etc. is all there.
  • sipaq: can at least try. can post to the l10n newsgroup about this, point them at it. a lot of them have a very active community, which will probably be willing to test this stuff.
  • wsmwk: yeah, I can make that posting. simon, you and I can (collaborate?) on that. was mentioned in the process leading up to firefox 3 that some localizers had problems getting ready. you guys will probably want to discuss what happened with that.
  • sipaq: ... we make a cut-off (~2 weeks ago for alpha 2) as to what looks like it's ready.
  • sipaq: I've announced myself to the community yesterday, planning to write up a post of how the build schedule relates to the localizers once all the issues are ironed out there.
  • wsmwk: do you want me to do that posting regarding alpha 2 for test builds prior to announcing them to the public?
  • simon: give it a shot.
  • davida: when is an ETA to have the BFT's done
  • wsmwk: I have friday the 8th written down. given that this is the first time that we're doing full BFT, it might be done as earlier as thursday, but I put down friday.
  • davida: need to give IT a heads up that we're going to change the website.
  • rebron: how much marketing do we want around alpha 2. probably don't want people doing reviews on it.
  • davida: so this release is called shredder. (branding was inconsistent for a1)... probably won't push the web-site stuff until Monday.

High-level Tb3 schedule

  • Thoughts on Thunderbird:Thunderbird3:Schedule schedule page?
  • Stuff that needs to be nailed down (all of these are probably slightly slushy)
    • String freeze
    • Feature freeze
    • Extension-API breakage freeze
  • Everyone: please make sure that all high-level features that you want to see in Tb3 have a bug filed and nominated to either block or as wanted.
  • thunderbird-drivers to-do list
    • Create calendar-integration flag
    • Lots of triage to do!
  • Other stuff?

Conclusions from meeting:

  • String freezes for beta1, beta2 happen one week before the code freeze.
  • Any bugs involving string changes that are pushing up against the code-freeze should have their strings broken out into separate patches that go in first, allowing them to make the string freeze while the code can continue to wait on review.
  • Nov 18th as final string freeze; late l10n can happen, but should be avoided.

Discussion from meeting:

  • dmose: (everyone look at timeline)
  • davida: what do we mean by beta1 and beta2. I know what rc1 means.
  • dmose: nothing too fancy. mainly feature freeze and string-freeze are important.
  • rebron: UI freeze?
  • standard8: that's basically feature freeze
  • dmose: all of this is slightly slushy, but I'm open to other theories on how it should work.
  • sipaq: from a localization point of view. individual string freezes for releases? final string freeze?
  • dmose: what do individual string freezes buy us?
  • standard8: time for the localizers to get their things together
  • dmose: if we don't, the cost is some won't be ready for the release?
  • sipaq: localizers don't like that, at least if they are active. my sense is 1 week or 10 days before the proposed cut-off date. normally, when you say the 9th of september, does that mean you produce a build then and give them over to QA, and then start producing the build on the 4th?
  • dmose: those are code freeze dates. so more like the first thing you said.
  • sipaq: then I would propose something like a week to 10 days before the code freeze. (for the string freeze for the individual release).
  • dmose: seems like a lot. I understand why the localizers would want that. but it seems like there would be a lot of churn.
  • standard8: historically, firefox, what they do if they have stuff that's going to go in but is waiting for review, they review the patch with just the string freeze, and get that in first. then they get the UI in once it gets reviewed.
  • sipaq: that's also how it happens in the calendar world too. get your strings in first, and take care of the UI later. there are always times when you push a string fix in, later in. we call it late-l10n string fixes. firefox does it a lot, we try and avoid it for calendar, but it nearly always happens. these are small things, like 1-3 changes per release, because localizers don't like that.
  • dmose: I'm certainly willing to start off with a 7-day ahead of time string freeze.
  • sipaq: what about the final? 1 week is way too short?
  • dmose: I agree for that. how about 2 weeks?
  • standard8: christmas...
  • sipaq: two weeks is way too short. some localizers will try and do all releases, some will only care about the rc. they'll wait until the rc is going to come out, and then they'll localize all the strings between TB2 and TB3 and all of the calendar strings. I would propose a string freeze at the beta2 release or shortly, one or two weeks after that. too hard?
  • dmose: I'm not sure. seems like something to try for. is it okay if we have a few late fixes?
  • sipaq: sorry?
  • dmose: if we say nov 15th as the string freeze, and say a few late-l10n after that. how's that?
  • sipaq: it should be okay as long as the late changes are far-reaching, and localizers don't get the intention that we're doing it deliberately. we should at least make an effort to get all the strings in for the string freeze.

( some minor discussion )

  • davida: we want as close to feature freeze as possible for beta 2.
  • sipaq: so, 1 week before the beta releases, nov 18 for string freeze.
  • dmose: the interesting thing to communicate may be that, we need to get everything in bugzilla and do a whole bunch of triage, so we know what's realistic and what we can get done. so you might want to communicate that this isn't 100% done. it could still change.
  • dmose: it's not clear how important of a goal it is to have a whole bunch of extensions ready to go at the time we release 3.0. I think it's a worthwhile goal, but it's not clear what we'd be trading against.
  • davida: by the end of 3.0, if we do a job right, we'll have a whole bunch more extensions than we had by the end of 2.0. of course, we don't want to piss off extension authors. we probably want to find out what the most important thunderbird extensions are and try and get them ported/make sure that they work. (ex: enigmail, etc.)
  • davida: so maybe a bug in there to identify top extensions and talk about early compatibility testing.
  • standard8: once we get to beta2, we need to stop mailnews cleanup and stuff like that . any API changes after beta2 are just bugfixes or things that we really really need.
  • dmose: sounds right to me.
  • dmose: everyone who wants something in thunderbird 3, file a bug in thunderbird 3 and file it to block or be wanted, depending on how severe it is. we're now trying to use block to indicate that "if this is the last bug, we really would hold for it", and wanted is everything else.
  • standard8: we did tweak that slightly with blocking-b1, so that we might adjust that for things we need to get into b1 for testing coverage.
  • dmose: that's a good point; feature-freeze bugs would probably want to block beta2. we don't have flags for all that right now. certainly the high order bit that we care about is blocking thunderbird 3. but keeping in mind that all this stuff has to land by beta2. probably worth getting all the flags created now so that we don't run into this again.
  • dmose: so from now, we probably want to be driving via bugzilla. the resulting to-do list for drivers is that we're going to have a calendar integration flag. and there's tons of triage on the driver's plates.

that's all I've got on the high-level tb3 stuff. anything else people want to talk about?

  • jcranmer: one question I want to have is how much of a goal is being able to add new account types in thunderbird 3.
  • dmose: I think it would be awesome, but I don't know how to answer the question.
  • davida: would it be awesome? yes. would we block for it, the impression I Got from last week is that we'd then ship in 2010.
  • standard8: I think account management, yes, it would be really nice to have that. I don't see any advantage in blocking on it, given that we don't have any extension authors shouting down our backs to get there.
  • davida: I think it would be really nice to be able to do twitter or IM back-ends.
  • (dmose: my doorbell is stuck on, I'm going to run down and try and deal with that)
  • davida: I think people would love to be able to do generalized messaging... if there's a way to do lightweight new accounts, that would be great, but otherwise I don't know.

(general conclusion seems to be we won't block on it)

Thunderbird:Thunderbird 3.0b1

  • Code freeze 9th September.
  • String freeze 2nd September.
  • Flags/searches are there.

Discussion From Meeting:

  • dmose: code freeze on 9th september. Standard8 has agreed to be the release driver on this one.
  • s8: as we've just decided, string freeze is 2nd september. we've already got the beta1 flags up, and I've already created the shared searches for that. I think that's it for now.

QA Updates

  • Held Bugday during Summit but poor results
  • In light of various new features that rely on offline/online infrastructure, we (devs, etc) should very concerned about all outstanding bugs regarding offline - it's a big list. Triage pending.

Discussion from meeting:

  • wsmwk: don't have much. given that we have a lot of features going in that rely on offline/back-end stuff. I talked to people on the way up to summit on the bus, and they mentioned problems that they have in this area. it seems like we should put a little bit of focus on it. I have a query there, and I've only started looking on it. but if you want to take a look on that, anybody, on bugs which you think you have some insgiht on, that would be great. I think we'll hit this on the next bugday.
  • davida: sounds like a really good buglist, sounds like something it would be good to have emre look at. would especially be great to know which ones can be reproduced.
  • (wsmwk indicated he is in contact with emre)


Status Updates


From meeting:

  • davida: great to meet all the mailnews people at the summit. it felt like a lot of the things we're trying to do fit realy really wel with mozilla overall. where data should live, how much control people should have over their data. I think we can be part of that story quite wel. the other one is the forward-thinking stuff that mozilla labs is doing, I think we can be part of that quite well. the only problem I had with the summit was I didn't get to talk with all the people I wanted to.
  • Spent much of the week doing summit stuff, including...
  • Getting the foundations of Weave working in Thunderbird. Some (though not all) is being tracked by bug 446444. I'll try and get bugzilla more up-to-date this week.
  • Upgraded Eclipse to version 3.4; and updated the page somewhat to help other folks

(not present)

  • Trying to fix bugday result queries post-bugzilla reorg. 7 Aug bugday should hopefully have fixed queries.
  • Summit (now catching up)
  • Reviews
  • bug 429891 Extra CR LF inserted every 10 KB in message in POP3 Sent folder
    • Also includes test case for sending a message from a file and checking that the message is correctly received at the server, and correctly saved to the sent folder.
  • Helped with hg switch over and did related bugs bug 446604, bug 446692.
  • bug 443351 Branding file relocation
  • bug 441526 Implemented highlightNonMatches in toolkit autocomplete.
  • bug 408613 Address Book preferences pane reconstruction

From meeting:

  • standard8: not much apart from what I've got there. oh, replacement menus for the menus in the addressbook which use RDF.
  • (summit)
  • lots of gloda progress! (but not enough milestones announced/tagged)
    • body extraction works (roughly speaking, it may extract 'too much' in multipart/alternative cases)
    • refactored indexing to use generators for cleaner logic
    • added starred/read/tag attributes
    • preliminary 'action' support added (provides the horrible check-boxes, but should have a use in a usable future as wel)
    • preliminary support for plugin-defined tables.
    • basic address-book card entry mapping (very basic), should get better with Dan's uuid mods.
    • exciting plugins leveraging the body extraction...
      • phone number recognition/indexing/searching
      • bugzilla is/references recognition/indexing/searching
      • URL recognition/indexing/searching
  • underway gloda things:
    • friendly query mechanism
    • nsIMsgDBView backed by gloda. This makes the inbox-fusion stuff do-able using gloda (plus all the other new folder-pane stuff), and a potential basis for cross-folder replacement under the traditional (non-expmess) UI.
  • near-term gloda/expmess plans:
    • get a first pass at auto-completing search-bar hooked up to the gloda-backed nsIMsgDBView. This will expose the gloda functionality that the horribly ugly 'data mine'/'data miner' checkbox explosion currently accomplishes. We (clarkbw) can then put the data mine back into useful shape and make it even more useful.
    • officially push a new milestone with XPI's
    • document gloda plugin creation on the wiki.


  • dmose: what about getting it into the tree? is it worth pushing XPI?
  • asuth: current new features could cause some changes, since I'm rolling iterative, so I figure after that it makes sense to push new xpi's etc. then I figure some unit tests and try and get it reviewed and into tree.
  • dmose: do we expect it to be feature-complete when it goes in?
  • asuth: pretty much, perhaps some additional high-level aggregation for extension authors. otherwise, I think most of the changes after that (for expmess) can just be in extension-space and we can avoid major API changes.

(not present)

  • Survived (enjoyed, even) Mozilla Summit. It was great to meet so many contributors for the first time.
  • Landed CondStore support bug 336151 and fixed a regression it caused bug 448558
  • Fixed bug 408861, alert about server not being imap 4 server when connection lost
  • Fixed crash if rebuild index is executed during compact, bug 392015
  • Fixed filter copy action after filter move action, bug 376235
  • Fixed bug 300487 saved search folder is bold w/o unread messages
  • Removed unused uuencode code, bug 216075
  • Working on adding support for threading and grouping in our saved search views - bug 379806
  • Will be traveling during the status meeting
  • Flooded in email
  • Glad to be back (in one piece)
  • Switched to Mercurial
  • Planning to resume work on offline message download:
  • Summit-ed plenty, survived, managed to get myself home eventually, with one more travelling hicup
  • Had lots of talks with the Release Enginering Team (and learned tons)
  • Buildbots are GREEN:
    • Nightlies
    • Builders
    • Unit Tests
    • Leak Tests wanted bug 428398
  • Thunderbird 3.0 Alpha 2 bug 445991
  • Mozilla Messaging CA and who gets access to our resources ?

From meeting:

  • gozer: (our resources?)
  • dmose: traditionally, play it by ear, as people that we trust need access, give them access.
  • davida: I totally agree, I think it means what you mean by access. generally I think we want to be flexible. since we have so much less in the way of valuable assets, we can probably be looser with our keys than moco can.
  • made excellent QA, localizer, and other contacts at Summit
  • numerous suggestions made about litmus, QAC (Quality Companion)
  • prepped for Alpha 2 QA
  • working to put up a global map of QA participants
  • used offline, online functionality heavily over past 1.5 weeks and finding it rather painful at times ... bugs etc
  • completed core mailnews QA and assignee cleanup 979 bugs with Serge´s help just prior to bmo reorg, and stage 1 of which is now completed

From meeting:

  • wsmwk: already got started with the l10n builds sign-off.
  • wsmwk: glitch in hand-off of alpha2 builds, so we lost a few days there.
  • wsmwk: one thing I think would be interesting would be to put up a map of where the QA participants are.
  • wsmwk: not too much going on until gerv gets back about changes in mozilla bug components.
  • ...
  • sipaq: does anybody know why there are no trunk l10n thinderboxes for thunderbird? for different locales which actually support thunderbird?
  • dmose: there's a bug on getting that with hg, but I don't think there were any in the past, are you asking why that is?
  • sipaq: I think there were (some that are on)... I'll ping Axel (Pike)
  • A lot of work on fakeserver:
    • It now passes some of Dovecot's IMAP server tests, but many fail because imapd doesn't handle two connections accessing the same mailbox
    • All that's needed is to add tests in imap/test
  • Posted morkreader (bug 424446) patch, awaiting reviews...
  • Ran Dehydra GCC on mailnews, no errors!
  • Attended summit, but had some annoyances with Air Canada on the trip back
    • Have notes for Tamarin Tracing, Static Analysis, and XPCOM GC sessions, will post soon

(not present)


(not present)

  • On vacation this week, hope comm-central works well enough until I'm back :)

(not present)

  • summit
  • Doing a lot of setup: getting acquainted with Mozilla Marketing/PR team, setup accounts for other mail services, Windows Mail, Windows Live Mail, Zimbra, etc.
  • Started quest for a Thunderbird plushie (or snowboard).

From discussion:

  • dmose: I encourage people to try and live in another mail client for a week or two or three.
  • rebron: I can put up write-ups of my experiences with other mail clients if that would be useful for other people. (extra: yahoo webmail, gmail, etc.)



  • sipaq will file a bug on getting a thunderbird aggregator going on
  • someone should file a bug about getting a planet mozilla messaging. (different from the thunderbird aggregator presumably in that it's inclusive of everything, where I think the thunderbird aggregator is targeted only to specific tags or other means of limiting the posts to thunderbird-specific things, possibly targeted.)


  • sipaq: what are the communication channels right now for getting things out on thunderbird? as far as I know there's the website, there's the individual blogs of people. but from a blog perspective, there's nothing there that's like an official blog or something.
  • davida: right, so we were planning on doing a blog on, or rather a planet messaging.
  • dmose: I think there's a different use case between an official blog and a planet.
  • davida: concerned about an official blog being a chore to do and a chore to read. I think we could have an official l10n blog that is relevant to the community.
  • dmose: my experience doesn't really match yours, but I agree that if people are finding it a chore to do, people will find it a chore to read.
  • sipaq: I'm thinking of pushing out 3-6 messages per year to localizers, so I don't think a blog is right for that, since I think it needs to have continual content. but with an official blog with other stuff covered, it would be enough content for a blog. stuff like dmose is publishing the release schedule. and the idea of planet mozilla messaging is a very good idea all by itself.
  • davida: so, two aggregators, one from the whole planet, and then an official one, from... somewhere... to me the calendar blog is interesting, it's at least semi-official. you know who's writing it, it has a voice, etc.
  • dmose: certainly something analogous to the calendar blog sounds interesting to me.
  • sipaq: okay, so where do we go from here
  • davida: so I guess there's two bugs. one to create an official blogger aggregator, and one is to... what are your thoughts rafael?
  • rebron: I need to check in with mozilla marketing on what they're doing. I think they do have an official blog. from a marketing perspective, it sounds good to have one aggregator.
  • davida: so I think this issue is about the outer circles of the community, not marketing. sipaq, do you think we should have an official blog with accounts for people, or an aggregator?
  • sipaq: from my experience in the calendar world, it only really works if someone is pushing everyone hard about it. I've been trying to do it. an aggregator would work too, it would probably work better. we don't have that, so we chose that alternative.
  • davida: the only problem is that people who want to post need to post a blog. why don't you (sipaq) post a bug about that against mozillamessaging and gozer will take care of that.
  • davida: talking to the l10 community, the dev community. people who are interested in thunderbird but not interested enough to pick the thunderbird bits out of planet.mozilla.


davida, dmose, standard8, asuth, emre, gozer, clarkbw, wsmwk, jcranmer, rebron, sipaq