Hi all. As of tomorrow, I’m off on a summer break. I’ve set up some templates and stub pages on MDC that I hope will help everyone write docs as they find time.
Start with the Overview page. There is a section for each Thunderbird “component” (ie, the address book, the message list, etc). Each section has a brief functional description, a list of the related interfaces, some ideas about what extensions developers could do, and a TODO list.
Although there are a few exceptions to compensate for existing material, in general each component also has:
A page that describes the interfaces related to the component (linked to the component’s section on the Overview page)
One or more pages that provides examples (linked to the component’s section on the Overview page). If the existing examples were snippets or non-existent, there is a single page with multiple examples. If the examples were large (like tutorials), there is a single page per example.
In some cases (such as Gloda), there is also an overview page specific to the component that goes into greater detail about thecomponent itself.
Some of these pages have content; some do not. Where there is content, some of it is recent and relevant, some is not.
To help out with the docs, go to the Overview page. Look at the TODO section for the component that interests you. Replace the prefix “who?” with your name. When you complete the TODO, put a strike-through over the text.
(If the TODO item is prefixed with someone’s name but has a question mark, that means that I made a guess that the assigned person would be the one to do it. If you want to take it over, talk to the assigned
person.)
If you create new pages (feel free to do so) please add the following templates to the top of the page (below the title):
FTP has latest-comm-central and latest-trunk symlinked to latest-comm-1.9.1 for the first part of the transition.
Those are static builds with reduced build size and hopefully better performance.
Dependent builds ("build" columns, "hourlies") continue to be shared builds.
Linux has a "leak test build" column that runs debug builds.
Nightlies and dependent builds are being run on x86_64 Linux, even though this should still not be considered a tier-1 platform and has no L10n builds.
Localized nightlies are in latest-comm-1.9.1-l10n and built with the "L10n merge" tooling that injects en-US for missing strings, eliminating most cases of the "yellow screen of death".
The SeaMonkey tinderbox waterfall page has those buildbots reporting as columns containing "comm-1.9.1" in their names.
Due to ongoing slight instabilities in the 10.5 VMs, the old "comm-central" 10.4 unit test machine stays up there as well.
All other comm-central builds disappear from the scene.
For localizers, the comm-1.9.1 builds on their Mozilla-l10n-* waterfall pages are the relevant reference.
All VMs on the same platform run in generic pools, so that any of the machines can do any dependent build, nightly, L10n repackaging or unit test run, the buildbot master hands those jobs on a "first come, first serve" basis to the available slaves.
Builds with mozilla-central are set up in addition, uploading nightlies to a latest-comm-central-trunk directory.
A version number of "2.1a1pre" is used there for now, there's no definitive decision on what version the next SeaMonkey will be yet though, this is the lowest possible version to use atm.
FTP symlinks for latest-comm-central and latest-trunk are removed.
The comm-1.9.1 builds are switched to report to a new SeaMonkey2.0 tinderbox waterfall page (as well as the 10.4 tests).
The comm-central-trunk builds report to the SeaMonkey page.
No unit test builds will be activated for comm-central-trunk while we don't have all the machines we need in the pools (due to Parallels network problems).
L10n builds for comm-central-trunk use l10n-central work and also report to the Mozilla-l10n-* tinderbox waterfalls, dashboard for this might only come up some time later.
A few other incremental improvements can be thought of when Phase II is completed, such as running packaged tests, AUS for L10n, etc. but all those can be done individually, step by step, then.
Once 10.5 Mac VMs are completely stable and not intermittently crashing because of Parallels issues, we'll turn off the 10.4 unit test machine and hand it back to Mozilla IT.
I hope this whole transition works well for everybody. It was a bumpy ride and a good amount of work to get this all up, but it largely reduced the amount of maintenance needed and makes us share more buildbot code with Firefox and Thunderbird already now and even more once this all is completed.
Thunderbird came around with setting up a schedule just in time, so at yesterday's SeaMonkey Status Meeting, we agreed on adopting Thunderbird 3.0b3 dates as the SeaMonkey 2.0 Beta 1 schedule as well (times of 23:59 US/Pacific, as usual):
This is the first time we have string freezes for SeaMonkey, so let me give you some explanation:
After the slushy string freeze, string changes should be avoided where possible, and those needed must get approval-seamonkey2.0b1+ before being checked in.
After the slushy code freeze, the same is true for any code changes, though blocking-seamonkey2.b1+ bugs without string changes can go in without further approval (blocking+ serves as approval).
The firm freeze should be the cutoff for any changes at all, unless there are blockers we still need to fix.
* I'm not completely sure about the freeze for L10n, we might not need that at all, as we'll likely do the same opt-in process as Firefox did recently and so might be able to just take any L10n changes up to the time when we start the builds. This is the first time we're doing that, so please excuse roughness in the process.
DXR, David Humphrey’s new tool for searching source code, looks really cool. It combines static analysis and source code search, so you can do things like search for the location where a variable or method call was declared or find the implementations of a method call. David has done a blog post and a video that describes features and usage. DXR searches either the mozilla-central or the comm-central tree.
The project is in early stages: right now DXR only works with C++ and IDL (JavaScript is in the works). Regardless, because of Thunderbird’s thin API documentation, tools like these are a huge help for Thunderbird developers.
Late last week, drivers spent some time discussing where we were at on the Thunderbird 3.0b3 front. We came to a decision that there's more value to be had by getting 3.0b3 out the door quickly than by continuing to hold it waiting for the last piece of the great search refactoring and the subsequent regression fixes.
The reasoning is this: beta 3 has already taken a long time, and it's felt somewhat stalled waiting on one set of things for a little while now. It was observed that there are now enough front-end changes stacked up in the tree that 3.0b2 bug reports have significantly decreased in value, and that effect is accelerating. Most importantly, it was pointed out that if we ship a milestone sooner rather than later, it helps replace that feeling of being stalled with a feeling of ongoing momentum.
What are the bigger picture consequences of doing this? Clearly, defaulted-on-GloDa search doesn't happen until b4. Then, as soon as b3 ships, we start going through the complete Tb3 blocker lists with a long knife, hopefully cutting enough that we end up feeling that our current ship targets are realistic.
This change in plans feels to me like it's mostly about partitioning the remaining Tb3 work to our advantage; it doesn't ultimately change the amount of work that we need to do.
So, where does that leave us in terms of beta 3? I've done a bunch of bug triage today, and I'll be proposing some dates in an email to dev-apps-thunderbird shortly. My expectation is that we'll come out of tomorrow's driver meeting with dates that we can work with.
Here's a summary of SeaMonkey/Mozilla-related work I've done in week 26/2009 (June 22 - 28, 2009):
SeaMonkey Build/Release Harness:
Followup work on getting SeaMonkey release automation (also has wiki documentation now) from testing into production to actually work is continuing. The main bug now has the SeaMonkey-specific configuration files attached for review, I tried to make repack independent of ChatZilla or venkman being enabled (doesn't correctly work yet, though), filed a bug and (trivial) patch for pretty names in Windows installer and added shipped-locales files to both trunk and the 2.0a3 release tag (release automation needs to fetch that file from the last release to determine what to generate updates for). The removed-files.in fixup I wrote up after analyzing update verification logs from the release harness has landed, which should also make us ready for shipping static builds in nightly updates.
I did a small update to the patch for DMG unpackaging in the buildsystem and updated the patch for repack factory abstraction once again for some bitrot from buildbotcustom changes.
Release Process: SeaMonkey 1.1.17has been released on Monday, containing a good number of security fixes compared to 1.1.16. I continued uploading contibuted builds as they came in.
Download Preferences:
As I start to see more and more people being confused about the behavior preference on the download panel not working I started the work on updating the download preference panel to reflect changes from the download manager switch. This will focus on making the behavior and location prefs work correctly so that 2.0b1 will behave itself, more improvements can be done in later followups building on this.
Bug Triage, Support Mails, Start Page:
I spent some time looking at bugs that were changed again after the large NEW->UNCONFIRMED change, trying to get actions to happen where possible, or deciding to WONTFIX them in a number of cases (such decisions need module owners or Council members in most cases).
Also, I finally came around to work the backlog of support mails I had in a subfolder of my inbox (I don't feel responsible for support, so I push them in there, but try to at least give some reply with pointers when I come around to it - might take weeks to months though). I ended up writing 70 replies in 4 hours, taking 3:30 minutes per mail, mostly with standardized replies, sometimes one or two sentences containing more specific help.
The "start" page on the SeaMonkey project website has been warning people that their alpha/beta builds were outdated when they were older than four weeks which is not the best idea in the light of e.g. Alpha 3 being four months old and still "current" right now. I finally came around to modifying the page to restrict this warning to nightlies and doing a special warning for non-current alpha/betas.
German L10n:
Fixed some ChatZilla and general SeaMonkey strings to keep the de locale green.
Various Discussions:
Checkin for packaged tests uploading glitch, DEL and other keys in download manager, OpenWebCamp Vienna, Parallels VM adjustments, FF 3.5 release preparations, Scheduling of Mozilla's Weekly Update Meeting, thundertab restore and SeaMonkey, etc.
I have a very strong opinion about how successful our planning of SeaMonkey 2.0 Beta 1 in sync with Thunderbird 3.0 Beta 3 went - and believe me, there's nothing positive on it. Since we defined a freeze for our first alpha, we have learned that only a definitely scheduled freeze date will bring people to pick up speed and concentrate on the really needed stuff for that release. Sure, there's a lot of stuff to do in general, but usually only a few items that really need to go into a release. Most people fail to deliver on those things unless there are deadlines for making it happen. Thunderbird 3.0 Beta 3 is a glaring failure in that kind of scheduling, and with making SeaMonkey 2.0 Beta 1 dependent on that milestone, we ended up with a miserable performance on scheduling and delivering ourselves. If we had know how long that short delay would take, we might have done an Alpha 4 just before the download manager landing and still would be ready to wrap up the beta right now.
In any case, I'll propose uncoupling this beta from the Thunderbird cycle, set L10n and code freezes to happen soon and deliver SeaMonkey 2.0 Beta 1 within the next few (meaning really few) weeks, independently if Thunderbird ships a Beta in the fifth month after their most recent one or not.
We'll set freeze dates at this week's SeaMonkey Status Meeting and follow up with posts on the relevant groups and lists.
Fixed: 384842
- Specially crafted subject lines (certain length, space at the end)
generated invalid mail headers
Fixed: 391272
- Scrolling/jumping to next message in threadPane works very
unfavorably because selected message is the first or last line
Fixed: 418623
- make thunderbird (qute/gnomestripe) use toolkit’s tree.css
Fixed: 436361
- “ASSERTION: selection count is wrong” or “ASSERTION: selected indices
is not equal to num of msg selected!!!” when opening a message in a new
tab
Fixed: 467888
- Window title does not reflect the current tab when messages are
selected
Fixed: 469006
- Open message in new tab shows empty tab
Fixed: 470689
- switching tabs doesn’t update toolbarbutton states
Fixed: 472316
- Opening tab from search matches is broken
Fixed: 474598
- The icons on the toolbar should change or disappear depending on the
tab selected
Fixed: 474701
- gloda global search on toolbar, folder display refactoring mega-bug
Fixed: 480623
- move compact message header view to an extension
Fixed: 481331
- Inconsistent folder selection display in title bar and task bar
Fixed: 482766
- ‘../removed-files: No such file or directory’ in L10n installer logs
Fixed: 487418
- New messages in junk folder shows new mail notificator
Fixed: 487580
- Message Tab Caption not updated when deleting mail.
Fixed: 489591
- No “more” button shown for multiple mail addresses although there
should be one
Fixed: 492555
- attachment reminder: Too common keywords, many false triggers
Fixed: 495113
- Clicking clear now in activity manager hangs thunderbird
Fixed: 495482
- After expand all, selected rows are not always visible
Fixed: 496543
- Marks folders as read only marks first folder
Fixed: 497337
- Enter virtual folder results in alert dialog The current command did
not succeed. The mail server responded:Can’t open /<blah>: not a
selectable mailbox
Fixed: 497383
- “Always keep starred messages” disappears from all accounts after
visiting deferred POP Disk Space settings
Fixed: 497895
- ugly iframe under feed messages viewed as “summary” (gnomestripe css
change forgotten)
Since 2009-05-10: 492279
- Sort out cookie handling within Thunderbird
Since 2009-05-29: 495478
- Buttons on summary page for collapsed threads don’t have same height
Since 2009-06-03: 496146
- tracking bug for build and release of Thunderbird 3.0 Beta 3 (3.0b3)
Since 2009-06-03: 496151
- What’s New page for 3.0 Beta 3
Since 2009-06-04: 496273
- Cannot unsubscribe newsgroup (Error: server is undefined)
Since 2009-06-08: 496884
- Collapsed summary view header hides message summary for threads with
long subjects
Since 2009-06-09: 497279
- Can’t switch to View -> Threads -> Threads with unread
Since 2009-06-11: 497572
- Error pop up not appearing when email address is invalid
Since 2009-06-13: 498155
- open folder in new tab is labeled “undefined”
Since 2009-06-14: 498209
- Recipient is no longer a choice for column list display in normal
(not Sent) folders
Since 2009-06-16: 498819
- Exception in nsIMsgFolder.msgDatabase when “no msf” condition. After
it, rebuild-Index is not invoked, Account Central is displayed for all
mail folders (”0×80550006 [nsIMsgFolder.msgDatabase]” at
dbViewWrapper.js :: DBViewWrapper_open :: line 762)
Since 2009-06-17: 499020
- If a thread is collapsed in the folder pane, deleting one message
from a message window “offers” to delete the whole thread when
selection has advanced to that thread
Since 2009-06-19: 499273
- “Delete Mail Marked as Junk in Folder” action in Tools menu doesn’t
work.
Since 2009-06-19: 499278
- non-ascii IMAP-folder names appear wrong after rename
Since 2009-06-19: 499410
- message header view: get rid of extra vertical whitespace N
Since 2009-06-23: 500123
- The gPlatformOSX is a lie, so the window title includes the
application name on OS X
Short answer, yes. You didn’t even need to say “pretty please”.
We’re beginning the work to update the Thunderbird icon. We really like how the Firefox icon turned out, and we’ll be working with the folks at Icon Factory so we can be consistent.
I’ve been impressed with how Alex Faaborg has led the charge with the Firefox Icon refresh, his vision, and his ability to communicate and work with everybody. We’re working with Alex as well, he’s got a great eye, and we’re lucky.
The Process
As I understand, it’s going to be fast and furious in terms of the design and feedback loop the next couple weeks. I’ll be posting a final creative brief before we get started, and happy to take feedback on it now. I’ll be posting the iterations and calling for feedback as soon as I get them.
It would be great if all feedback can be done as comments to these blog posts as opposed to direct emails to me.
The twittersphere is abuzz with the current twitterstorm about Microsoft’s plan to use the “Word HTML engine” in the next version of Outlook. It’s a campaign that’s an organization which represents people whose living depends on their ability to make compelling HTML pages in email, so it’s not surprising that they have a beautiful site which is getting a lot of people to retweet.
There are lots of campaigns that sweep the social networks on a regular basis, and this one is somewhat noteworthy because it’s about plans for a very commonly used piece of software, coordinated by marketers, and because the twittersphere is very receptive to anti-Microsoft sentiments. None of that is what I want to talk about.
What I want to dig into a bit is how Microsoft got there, and the implications for the Open Web. I’m not an expert on Microsoft’s history, or Outlook. But I can make a few guesses, based on how I’ve seen similar things evolve.
Outlook became the dominant enterprise email client during a phase of Microsoft’s life where embracing the web sometimes meant making stuff up and pretending it was a standard, or equivalent shenanigans. This was clear in Internet Explorer’s explorations outside of the normative specs, but it seems that some of the same “we can just do our own version of HTML” affected the Word team. This makes sense — if you’re a company with market dominance and the web is not central to your value proposition, but office productivity software is, then you’re going to do what you can to make the best user experience possible for your users, even if it means that messages sent to non-customers can’t be read with as much fidelity as those sent to customers. In fact, in a very basic way, that’s standard marketing — make using your product look better, so people want to use it.
Microsoft, again logically, invested lots and lots of millions of dollars into making design tools for Word, and HTML was thought of as an export format, where low-fidelity was almost a commercial virtue (”you don’t really want that”). The poor folks in charge of Outlook, who are mail experts, not HTML rendering wizards, had to deal with the use case of: “I want to send rich documents by email”, which blended office concepts (rich documents) and network concepts (email). They had to choose between a moribund IE6 engine, and the maintained, evolving HTML engine designed for use in Word. Given that most emails read in Outlook probably are written in Outlook and that Outlook users know the Word authoring tools, it was a rational choice. It made life hard for email marketers, and for a few people who like to use HTML to express their creative side and who do care that all their correspondents can see what they intended to send. But compromises are inevitable in a gigantic, complicated company like Microsoft. Had I been the manager in charge, given their constraints, I may well have made the same choice.
Now, it’s 2010 (or almost). Outlook is due for a new revision (gotta get the upgrade revenue). The choice is stark: adopting a more standards-compliant engine like IE8’s makes sense in the framing of “html email messages going out on the net”, but to deploy it in the reality of Outlook (mostly internal emails, lots of document ping-pong, etc.) it would require that Microsoft have a stack of design tools to offer that could realistically replace their existing stacks. There’s the rub — good HTML engines aren’t useful in a user context like Outlook’s if the authoring tools weren’t built with real HTML/CSS in mind. And neither Word’s venerable composition tools or Silverlight’s new-fangled ones were. So the Outlook team is stuck with a product that needs an upgrade and a need for both composition tools and a rendering engine, neither of which it can control. It’s not going to end well for at least some people.
[As a side note: the pragmatist in me wonders whether Outlook could use the Word HTML engine to render emails from Outlook users, and the IE8 engine for emails not from Outlook users. As long as no one ever edits forwarded emails it'd work!]
Now, it’s awful easy to make fun of Microsoft. The story on the side of the Open Web is better in part, but there are areas needing improvement. On the rendering engine side (displaying beautiful documents with fidelity and speed), the world is looking better than it has in years, with several rendering engines competing in healthy ways like standards compliance, leading-edge-but-not-stupid innovation, performance, and the like. Life is good. For email marketers, getting email clients to render real web content is all that matters — they pay professional designers to author their HTML content using professional web page composition tools, and the revenue associated with a successful email marketing campaign makes those investments worthwhile. Email is just a delivery vehicle to them, and it’s a perfectly valid perspective. They like Thunderbird a lot, because we’re really good at rendering the web, thanks to Gecko.
However, for regular folks, life is not rosy yet in the Open Web world. Authoring beautiful HTML is, even with design and graphics talent, still way, way too hard. I’m writing this using Wordpress 2.8, which has probably some of the best user experience for simple HTML authoring. As Matt Mullenweg (the founder of Wordpress) says, it’s still not good enough. As far as I can tell, there are currently no truly modern, easy to use, open source HTML composition tools that we could use in Thunderbird for example to give people who want to design wholly original, designed email messages. That’s a minor problem in the world of email, which is primarily about function, not form, and I think we’ll be able to go pretty far with templates, but it’s a big problem for making design on the web more approachable.
There are some valiant efforts to clean up the old, crufty, scary composer codebase that Mozilla has relied on for years. There are simple blog-style editors like FCKEditor and its successor CKEditor. There are in-the-browser composition tools like Google Pages or Google Docs, but those are only for use by Google apps, and only work well when they limit the scope of the design space substantially (again, a rational choice). None of these can provide the flexibility that Ventura Publisher or PageMaker had in the dark ages; none of them can compete from a learnability point of view with the authoring tools that rely on closed stacks; none of them allow the essential polish that hand-crafted code can yield. That’s a gap, and an opportunity.
I think radical reinvention is needed. Something with the chutzpah of Bespin, which simply threw away most of the stack that we all assumed was needed, but this time, aimed at the creative class (and the creative side in all of us), rather than the geeks. I know that lots of folks at Mozilla would love to help work on this, but we know we’re too small to do it alone. We know what modern CSS can do, we just don’t know how to make it invisible to authors.
This is a hard task, because it’s about designing design tools, which combines psychological, social, product design, usability, and technical challenges. It’s a worthy task, though, and one that I’d love to see someone tackle, especially if we can get non-geeks involved. There are tens of thousands of web designers who know the magic triad of 1) design, 2) HTML/CSS, 3) what aspects of existing tools make them productive, and what aspects fail. If we could get them to work productively with the tens of thousands of open source developers who currently build the applications that power the net (web, email, and others), we could throw away the broken metaphors of the 20th century and come up with new ways of designing using web technologies that everyone could use. Or maybe we just need one brilliant idea. I’ll take either.
We've talked about pursuing the benefits of specialization in the Thunderbird review ecosystem occasionally for a while now.
Over the last year or so, Andrew Sutherland has written lots of excellent, well-documented, well-tested code. It's been obvious to a number of us for a while that Andrew would make a fine reviewer and module owner and that the comm-central community has been missing out by not yet offering him the chance to apply his talents this way.
Recent landings have made it particularly clear that there are increasingly large areas of code in the tree that should be under his supervision: none of the rest of us know it as well as he does, nor do we have the same vision for how it should evolve.
So, in an overdue move, we've created several new modules. Under mailnews/:
The expectation is that where there aren't initially module peers, Andrew will add them as it becomes clear to him which people fit those roles best.
Thanks, Andrew, for the good work you've already done and for agreeing to help with module ownership and reviewing going forward!
In the bigger picture, there are more sub-modules that we can and will split out as time goes on, but these seemed like the most important ones to make happen now.
Release Process:
Continued the SeaMonkey 1.1.17 release process towards a planned public release in sync with Thunderbird 2.0.0.22, containing a good number of security fixes compared to 1.1.16.
Misc Work:
Did some changes in how my SeaMonkey development website retrieves and stores data: Weekly Bugzilla stats are now requested more efficiently using the microsummary ctype instead of full lists to retrieve the count and the results are kept in a DB, once I have more data and time, I'll make more than 3 weeks available on a separate page. Also, SeaMonkey 1.x update notification ping stats are now stored in a DB on the server, still need to write a report on those.
I also fixed the Thunderbird and SeaMonkey nightly file paths on www.m.o/developer.
Various Discussions:
DEL and other keys in download manager, OpenWebCamp Vienna, Bugzilla improvements, NEW->UNCONFIRMED mass change, etc.
With all the work I did put into that in the last weeks, I hope we will be able to actually ship the SeaMonkey 2.0 Beta 1 release off the automated harness which can produce L10n builds as well as partial updates, both of which we didn't have previously. Additionally, using that buildbot-based mechanism makes it much less manual work to get the release done. We still need to do a bit of discussion if we can live with using so-called "pretty" file names for the release (e.g. "SeaMonkey Setup 2.0 Beta 1.exe" instead of "seamonkey-2.0b1.en-US.installer.exe") and we also have no signing infrastructure for Windows builds, but we can fake it by copying unsigned builds to the final place and continue to ship unsigned releases as we did up to now.
Next to that, I'm realizing that a few areas of our project are pretty dormant and I can't find time myself to move them much forward myself. this especially concerns QA and marketing. We really would need people to help making progress there - if you can support us in any of them, please contact me!
Released on 22
Jun 09, and this changelog was last updated on 23 Jun 09.
Mozilla
Thunderbird 2.0.0.22 has been released. Release notes are
available. This post lists the improvements in Thunderbird
2.0.0.22 over 2.0.0.21. This list encompasses almost every single known
fix that went into this release. Do check out the known
issues as well.
The Gecko 1.8.1.x branch (Thunderbird 2.0.0.x series) will not
include any features that Gecko 1.9.x will bring, since it is based on
Gecko 1.8.
Critical:
Vulnerability can be used to run attacker code and install software,
requiring no user interaction beyond normal browsing.
High:
Vulnerability can be used to gather sensitive data from sites in other
windows or inject data or code into those sites, requiring no more than
normal browsing actions.
Moderate: Vulnerabilities that would otherwise be High or
Critical except they only
work in uncommon non-default configurations or require the
user to perform complicated and/or unlikely steps.
Low: Minor security vulnerabilities such as Denial of
Service attacks, minor data leaks, or spoofs. (Undetectable spoofs of
SSL indicia would have “High” impact because those are generally used
to steal sensitive data intended for other sites.)
Changes in
2.0.0.22: (11)
Security issues: (7)
Fixed: MFSA
2009-33 – Crash viewing multipart/alternative message with
text/enhanced part (High)
Fixed: MFSA
2009-14 – Crashes with evidence of memory corruption (rv:1.9.0.9)
(Moderate)
Fixed: MFSA
2009-24 – Crashes with evidence of memory corruption (rv:1.9.0.11)
(Moderate)
Fixed: MFSA
2009-29 – Arbitrary code execution using event listeners attached
to an element whose owner document is null (Moderate)
It's time for another status update again. We're hard at work to finally get our next release (1.0 beta) out of the door for Lightning and Sunbird. Over the last three weeks we have fixed 31 bugs, which are listed below.
Bug 273279: no visual status mark on tentative or cancelled events/tasks
Bug 387014: While reloading remote calendars, Thunderbird windows are unresponsive
Bug 389088: Use default alarms defined in Google Calendar
Bug 395281: Attendee icons in Free Busy Pane need tooltips to be understandable
Bug 404902: View calendar while refreshing remote calendar
Bug 410050: description is taken from wrong e-mail message
Bug 491326: Non-ascii calendar names are displayed wrong after restart
Bug 491868: print card/contact is completely unstyled and hard to read
Bug 492723: Error "favoriteFolderMenu is null" opening the Edit menu from Lightning
Bug 494160: Event dialog: Add accesskeys for menuitems in menu "Options - Status"
Bug 495859: Lightning notification bar appears at the bottom of the message pane.
Bug 496413: faulty PROPFIND will not declare the request as complete
Bug 498158: Context edit menu (undo/cut/copy/paste) has got no icons
Bug 498700: imip bar is not displayed, error "GetLoadedMessage is not defined"
Bug 498779: Outdated information in /calendar/lightning/nightly/README.html
Bug 499500: Error "GetFirstSelectedMessage is not defined"
Bug 499540: Multiweek View: changing Number of Weeks via View menu fails
Bug 499588: TB3 integration: Fix accesskeys for File -> New menu items
As always, our thanks go to all developers, contributors, localizers, testers, and supporters that have made this possible.
PS: We've read and noticed the repeated requests for a more high-level plan of our future goals (some call it a "roadmap"). Philipp is currently working on a blog post, that will hopefully satisfy those of you, who were kind enough to get in contact with us and ask us for such a high-level plan. Stay tuned!
I'm sorry, but I totally forgot to tell, that we currently expect to have the 1.0 beta release ready in about four (4) weeks from now. So that should hopefully give every localizer enough time, who have not been following our checkins on a daily or weekly basis.
I'll inform you as soon as I know about a definitive code freeze and release date.
Today, the SeaMonkey project released a new version of its all-in-one internet suite. SeaMonkey 1.1.17 closes several security vulnerabilities and fixes a few smaller problems found in previous versions.
It's been a long time, but it seems that we're finally getting near to a new release. Yay!
Philipp tells me, that we now have only five open bugs on the blocking list that are needed for the 1.0 beta release. All of those bugs have no localization impact, which means that we are ready for a string freeze.
We will therefore freeze all application strings by tomorrow, Wednesday, June 23 at 23:59 PST. That means that all strings will then be entirely frozen until we release Lightning and Sunbird 1.0beta. I will open up a separate opt-in thread for localizers in the mozilla.dev.l10n newsgroup soon.
One additional note to localizers: Please take a close look at the status of your tinderbox (at http://tinderbox.mozilla.org/showbuilds.cgi?tree=Mozilla-l10n-locale where "locale" must be replaced with your locale code (e.g. es-ES or de). I've seen some locales having a red Windows tinderbox (and therefore broken Windows builds), because those locales didn't follow this change to our installer strings. Please check if this applies to you and make the necessary changes.
In an effort to better integrate into Thunderbird and also to clean up some very evil workarounds we have reworked the Menu Structure of Lightning. Work on this was completed yesterday in bug 456385.
Previously, we switched the contents of the whole menu bar when changing from mail mode to calendar or task mode. Aside from the fact that this forced us to use very heavy workarounds for certain platform-specific bugs, this only made sense for 0.9, since the modes were very dedicated. I believe this was also a nightmare with regard to accessibility.
To fit better with the new tabbing mechanism available in the Thunderbird 3 betas, we changed this mode switching logic to show each mode in a tab. It looked a bit awkward that the menus change, just because you switched to a different tab.
Therefore we aimed at an integrated solution that has a fixed menu for manipulating events and tasks, and sorted our other menu items into the existing menus. Aside from that, the idea is to provide buttons and other actionable controls right in context - the user shouldn't have to travel far to do what he wants to do.
Please take a look at our latest nightlies together with Thunderbird 3 beta 2 or later to get a feel for the new menus and to find out if there are any missing pieces.
Last time I played with Review Board and bugzilla request queues things were great for me, but no one else. I had to create an account for you on the instance, add you to my script that synchronizes request queues, run the script, and then keep running the script periodically. Not to mention there wasn’t really a way to get your review out and into bugzilla. No one actually tried to use it, so they probably also didn’t notice there were caching issues related to the ever-changing definition of “HEAD” (”tip”). It sucked, and when I upgraded and everything broke, no one cared, not even me.
But now it’s back and better than ever:
People don’t need to login at all to see review requests and reviews! Just point them at the URL and away they go. (Actually, this was the case before, but it was not obvious.)
You can/must sign in with Open ID! If you have Weave and are reading this in the future, Weave can be your Open ID friend! If you are like me and live in the present (Weave 0.3.2), something is wrong and it doesn’t work, not to mention that Weave takes over the Open ID box so you can’t use credentials that work.
There’s a button that updates your request queue for the 16 most recent requests made of you. Just make sure that you have entered your bugzilla e-mail address on the “my account” page. This may have happened automatically depending on what your Open ID provider provided/you told them to provide.
There’s export functionality so you can take your review and cram it in bugzilla.
The definition of “tip” gets nailed down when the review request gets created, so no more ugly caching issues. Patches can still fail to apply, though, if “tip” has drifted from when the patch was first created.
It has friendlier assumptions about what repo you are dealing with. Thunderbird/MailNews Core/Calendar/SeaMonkey are all assumed to be in comm-central, everyone else is assumed to be in mozilla-central. Patches against other repos (including mozilla 1.9.1) clearly will not work without additional logic (and some kind of extra info, like people putting “1.9.1″ in their attachment descriptions.)
Here is a (fake) example of the “pretty” review output that is possible if you tell people about your reviewboard review (see it live here). Although it says Bienvenu, it’s just me pretending to be him because his review queue is more interesting than mine. The comments are accordingly mine.
Now, what does the export look like (see it live here)?
on file: mailnews/base/src/nsMessenger.cpp line 635
> // if we have a mailbox:// url that points to an .eml file, we have to read
> // the file size as well
what a pretty comment
on file: mailnews/base/src/nsMessenger.cpp line 642
> NS_ENSURE_SUCCESS(rv, rv);
please rename rv ARRRRRR-VEEEEEE
Yeah, it looks like that.
A quick feature summary that explains why this is better than just looking at diffs in bugzilla:
Syntax highlighting!
It actually has the full-context of the rest of the file! No more being limited to the 3 or 8 lines of context in the diff you are provided. I know I have done a lazy review and let a bug through that would not have happened if I had more context at my fingertips (or was not sometimes lazy).
People just trimming down your patch to what they are commenting on leaves you with no context of what changed at all!
The root of the review board that will prompt you to login via an Open ID account. When syncing your review queue, please keep in mind that it can take a bit to do all the legwork and you won’t see any feedback until it is actually done doing everything else. You should get some form of feedback no matter what happens, so don’t keep hitting refresh.
The hg repo for my modified version of review-board. It’s based on an extremely shallow hgsvn checkout. My questionable development strategy was to make changes with emacs locally, commit, then push to my VM, so the changesets are sometimes a bit excessive.
Caveat usor:
This is running on a linode VM right now. This is better than my local box or what not, but it’s not Mo[MC]o IT or anything.
My changes, at least the export functionality, may be buggy. You may need to rely on me to fix the export functionality to get your stuff out that way. (If the hg diff doesn’t apply cleanly, you can’t enter data to lose it, so I’m less concerned about that.)
I have no plans to blow away the database, but at the same time, please be prepared for the possibility that space ninjas destroy your data. Use the export functionality and save it to a text file or something periodically if you’re doing a major review. (In case it’s not obvious, the export functionality is the text labeled “bugzilla-style export” to the right of the reviewer’s name at the top-left of each review.) You can do your review in multiple passes, exporting each review pass individually.
I am confident something will go wrong. Feel free to post comments here or ping me on IRC (:asuth).
If people actually try using this, I’ll stop developing on the live server, but do be aware that apache restarts (lasting a few seconds) may periodically happen, but this should not really impact anything.
Because there's a fair amount of work that still needs attention from the core developers before we can ship Thunderbird 3, thunderbird-drivers have been thinking hard about how we can ship the best possible product in the shortest possible time. The attention of the core development team is already spread far too thin, and we're concerned about shipping an app that tries to do too many things, at the cost of all of them having too many bugs and not being polished enough.
As a result of this, and because the feedback related to the compact header was different than expected, we decided in bug 480623 that moving it out of core was a reasonable trade for winning some focus back. The patch landed this morning, so upcoming nightlies will no longer have the compact header.
First off, we understand that removing this from core is going to disappoint some people and apologize for that. That said, the fact that the core team doesn't have the bandwidth to maintain the compact header doesn't mean that other designers/developers shouldn't be able to continue to provide it if they so desire.
As part of the removal work, I factored the compact header code into a prototype extension. This turned out to be valuable, because without it, I wouldn't have known to add the extension hooks necessary for that to actually be possible. The code for this extension is available from a Mercurial repository. I do not have plans for further work on it, but if anyone reading this wants to move it forward, I'd suggest setting up a MozDev project and adding a comment here pointing to it so that other interested folks can join in.
This removal will free up bandwidth to focus on the remaining message header. Current plans (besides bugfixing) include (but are not necessarily limited to):
work on squishing down vertical space requirements
more extension point work (both documenting the changes and adding more extension points)
investigate whether switching some of the nested es to s will fix some of the current bugs and make for more maintainable code
investigate the right level of in-app customization to provide
I understand that riding out the development iterations of UI can be bumpy; I appreciate folks' patience.
(Note that I won't be around on the weekend to approve or reply to blog comments).
David Boswell has an update on his blog about the changes on http://www.mozilla.org. Previously, the site was a catch-all of technical and project management content. The site is becoming more of a general portal site for Mozilla products, projects and communities. Recent and relevant project management-type stuff is being moved to the Mozilla wiki, and technical stuff is being moved to MDC. (Hopefully we’ll be able to salvage a few documentation gems for MDC.) Lots of content. however, is simply being archived. Redirects galore.
If you run into problems with finding content, or would like to suggest content that should be moved off the archive server to MDC or the wiki, please email the mozilla.org webmaster or myself.
Two days ago, I was invited by Outblaze
Limited to give a talk about the Mozilla development / test process
at Cyberport, Hong
Kong. (Preliminary thanks
especially go out to Yusuf.)
I primarily covered the following topics through live demonstration:
What’s new in the upcoming releases Firefox 3.5 and Thunderbird 3
QA process in Bugzilla – triage through review and checkin. Bug
lifecycle.
Because I had an hour slot, I didn’t have time to cover the
Tinderbox waterfall, Litmus, and some other things I wanted to
cover
(perf tests, Talos, etc.).
It was my first time speaking to seasoned engineers (some IBM folks as well, I think)
and I was glad I
could share my experience with them. I had given talks (so far
numbering four in total) to undergraduates, graduates, and
professors
(spanning from schools in Singapore /
Hong Kong and now a company) but
it was really special conversing with engineers because they knew what
they wanted to know, and I also had quite a fair share of interesting / challenging
questions. They seemed particularly interested in Mozmill testing
(Mozmill folks, reading this?)
especially with regards to testing web
applications. In hindsight, I really should have demonstrated my
Bugzilla Mozmill test. Anyone remembered “Gristmill
in Action“?
I hope to be able to share more of my experiences in the future, as it
both enables my audience to learn more and myself to give better
speeches in the future. Having made some great friends (Yusuf, Sultan,
Milan, and some others I forgot to mention), I am glad I was
able to
share my knowledge with you guys – I learnt a lot too, I’m sure this
help me improve over the next two years before I graduate (I’m still an
undergraduate, and [im]patiently waiting for time to fly by).
Lately I’ve been working a lot on the Thunderbird add-ons developers user experience. Often times designers don’t get to work on developer experiences because developers tend to do those pieces themselves without much design. With a lot of others I’ve spent a good amount of time working on the whole experience of development, docs, and extension types so hopefully the Thunderbird 3 add-on developer experience will be significantly better.
To get into the user experience of an add-on developer I recently made a Jetpack, Bugzilla Air Traffic Control, to examine what it is like to develop inside Jetpack. I’ve also been creating a number of example extensions that take advantage of the new code that has landed in Thunderbird recently and learn the pitfalls of extension development.
To demonstrate the awesome interactiveness that I didn’t add to my email extension I also have a pure HTML demo available. Try out the email cube test demo for yourself. This demo requires Firefox 3.5, go get it if you don’t have it.
If you’re asking “why email in a cube,?” then I’ll ask you why not? This demo reminds me that Thunderbird has all the same Firefox goodness that’s coming out in 3.5 but we have yet to take advantage of much of it. Hopefully as we make more progress in the coming months we’ll do just that.
And if you’re asking yourself… Is this what Bryan gets paid to do? Well then we’re asking ourselves the same question; though I don’t think I’m referring to myself in the third person.
Release Process:
Continued the SeaMonkey 1.1.17 release process towards a planned public release in sync with Thunderbird 2.0.0.22, containing a good number of security fixes compared to 1.1.16.
German L10n:
Updated the tree for a few mailnews changes and the exclusion of PalmSync as well as a ChatZilla change and a mozilla-central change to about:plugins, but only after verifying that the "merged L10n" SeaMonkey builds worked even without those changes, displaying the missing strings in English.
Various Discussions:
Bugzilla improvements, NEW->UNCONFIRMED mass change, Thunderbird API refactorings, Firefox 3.5 going for RCs, etc.
Our friends in the Thunderbird project are making nice steps towards cleaner APIs for the mail and news back- and frontends (this week it was folder display and thread pane, earlier they already improved the folder pane itself), it would be nice if someone could help bringing those improvements to SeaMonkey, which would make it easier to work on other code improvements - something you, my dear reader, could help with?
Our regular nightly build testers may already have noticed. If you haven't here's a heads-up for you.
Bug 481685 was just fixed. The aim of that bug was to align the nightly build directory structure on the mozilla.org ftp server of Thunderbird, Sunbird and Lightning. Here's a n overview of the changes:
Since its inception, Thunderbird has offered
the ability for developers to write add-ons. In Thunderbird 3,
we're adding a new database layer that will allow extensions to easily
do more powerful and performant queries on your data. This will
add to the system's generativity, and
by taking another step in that direction, we can level up even
further.
We can do better by providing powerful
building blocks that Thunderbird-as-platform doesn't offer
today. Making it easy to render visualizations will encourage
developers to explore ways to give people insight into their messages, conversations, and usage patterns. Having access to the sorts of animations and effects that make for richer and more intuitive interactions will make Thunderbird and its add-ons easier and more fun to use.
We can do more by attracting the talents of new developers, and by making our platform easier and more enjoyable to code for. The largest pool of developers that we can hope to draw interested hackers from is the reservoir of web developers, and one thing that we'll need to do to that end is to make our platform more comfortable to them.
Given that the folks working on Thunderbird today already have a very full plate, this isn't something we can hope to do by developing new code. However, by taking advantage of good, appropriate open-source solutions, these are achievable goals for Thunderbird 3. In particular, bug 494962 has had substantial discussion around:
In addition to making a large group of web developers feel at home, this also will make it
easier for current developers to implement UI in HTML when that's more
appropriate. While jQuery is primarily written for use around
HTML, some (most?) of the utility functions for working with the DOM
and CSS are not HTML-specific. With luck, this should allow us
to get rid of a non-trivial number of hacks in the front-end code that
are either one-offs or are insufficiently
maintained/tested/optimized/generalized due to lack of
bandwidth.
jQuery UI provides a set of capabilities that enrich the baseline jQuery. Not all of jQuery UI is as applicable to Thunderbird, though, so we're only thinking about including the most often used and appropriate bits of jQuery, such as animation effects.
We're already using the Protovis visualization toolkit in some of our planned feature work, and it's a powerful framework for add-on developers to build interactive
visualizations that are based on open web technology.
David
Bienvenu and I have, wearing our module owner hats, agreed that this
makes a tremendous amount of sense, so we'd like to see it happen.
There's a bunch still to be done before this is truly nailed down
(there are a number of discussions we'd like to have around various
logistical ramifications). In the bug, DavidA links to a few wiki
pages that track this work.
Next steps:
DavidA to drive protovis into the tree by working through the tasks on that wiki page (hopefully for b3)
dmose to drive jQuery/jQuery UI in (for b4)
Folks are encouraged to followup to this post freely. If, however, you wish to comment in the bug itself, please only do so if you've read the entire thing and have something new to contribute.
With the recent switches from cvs to hg and then the addition of the 1.9.1 branch, the Thunderbird, Lightning and Sunbird nightly directories on ftp are a bit untidy and are in need of a late spring clean to make them clearer for nightly users downloading our builds.
Unless there are any major objections, we will be actioning this change on Tuesday 16th June.
Please be prepared to update links to builds. We’ll be covering all the mozilla.org/mozilla.com/mozillamessaging.com ones that we can find.
The changes will affect the latest-* sub-directories, resulting in the structures summarised below. The changes may also affect the names of the dated directories.
latest-* directories remaining as a result of the proposed changes (any latest-* directories or symlinks not listed will be deleted):
So this Jetpack does a pretty simple thing to help you avoid the mid-air collision by notifying you before it’s about to happen.
For every tab you have with a bug open this Jetpack does a simple check in the background to see if someone else has modified the bug while you were looking at it.
Code
The code for this is pretty simple and in total it probably took me only an hour to get up and running and then a bunch more time polishing things off. Here’s the break down.
I have a simple regex to find urls that are showing a bug:
var show_bug_regex = /^https:\/\/bugzilla\.mozilla\.org\/show_bug\.cgi\?id=(\d+)/;
Then I check if the url matches whenever a new page is loaded in a tab:
jetpack.tabs.onReady(function(doc) {
// here we setup our persistent check
var match = this.url.match(show_bug_regex);
if (match) {
init(this);
this.bug_id = match[1];
startCheckingTab(this);
}
});
Also for good measure I do a similar check when a tab is focused, in case the Jetpack wasn’t installed or running during the original load.
jetpack.tabs.onFocus(function() {
// here we just double check out status
var match = this.url.match(show_bug_regex);
if (match) {
/* if we've already notified then we aren't checking anymore */
if ( alreadyNotifiedTab(this) )
return;
if ( ! areCheckingTab(this) ) {
// they focused a url match that we haven't been checking!
init(this);
this.bug_id = match[1];
startCheckingTab(this);
} else {
resetCheckingTabInterval(this);
}
}
});
The start checking function simply runs an ajax request against the bug on an interval. All that was needed for this was to know if the bug had changed from the last time we looked so we build a url that only retrieves the delta_ts field to create a Date object.
BugXhibit, the Bugzilla search results viewer made with the SIMILEExhibit widget, is now more fancy, and now addresses another one of my use cases. I frequently find myself wanting to point someone at a bug, or go back to a bug that I know passed through my bugmail recently, and have trouble finding it. So now BugXhibit can do easy searches based on reporter/assignee/cc/commenter with time ranges.
Examples by way of live links this time (noting that the default time interval is 7 days). Uh, and if it gives you an error for reasons I don’t fully understand if you open it in a new tab (in the background) from here, just hitting enter in the address bar should fix it. I’m going to lazyweb that problem for now.
It now is also self documenting, just click on “Show Docs” on the page.
You can now use arguments to specify the sort and whether grouping is active on the page.
The date parsing is better. Bugzilla doesn’t provide the raw dates but attempts to change things based on how recent the date is. BugXhibit does a good job of fixing up the date if you are in the same timezone as the bugzilla server, and a less good but acceptable job if you aren’t.
Upgraded to exhibit 2.1.0 and now the numeric sliders with histograms work for me. Woo!
Tomorrow’s nightly build of Thunderbird 3.0 b3pre adds support for the IMAP Compress extension - see Bug 401673 and the rfc for more info. If the server advertises COMPRESS=DEFLATE, we will do compression of incoming and outgoing data. For lower bandwidth connections, this should be a nice win, especially when we select large folders and fetch flags. I’ve seen reports of > 5x compression for the flags response. To turn it off, you can use the config editor to toggle mail.server.default.use_compress_deflate to false.
The latest versions of the Cyrus IMAP server supports COMPRESS=DEFLATE. Fastmail.fm has rolled out this support already.
Many thanks to Bron Gondwana who developed the patch very quickly and cleanly, despite having no experience with the Mozilla codebase.
The above screenshot is of a normal search query on DevMo for “customize toolbar”. I see 2.5 results, and I honestly have no interest in the first item at all. (It’s a page that only advanced DevMo authors would care about, for those who refuse to squint or click on images to see bigger versions of images.)
The above screenshot is of the same query using DevMoXhibit. You will note you can see more things, and the first result from the other page is completely elided because we filter by default so that only “Real” result pages are shown. (In general, I am not looking for talk pages or user pages or meta-pages.)
But enough about my interpretations of pictures, why don’t you:
Neat things we do that may not be immediately obvious:
We flatten the score into deciles, and then within each decile range we sort based on the view count for the page. The theory is that, given equally likely results, the one that more people have looked at is probably more interesting to you, roughly speaking.
We use a simple heuristic to figure out the page type, as mentioned above (”Real”, “Talk”, “User”, etc.)
We try and hide all things related to the language, as we explicitly query on a language which means it’s just noise. Right now, that language is always english, but the code uses a variable if you want to write the code to hook that up and expose it in the UI.
We produce a “smart” snippet. The snippets provided by the search results naively will include “chrome” that is part of the document, which makes for a nearly useless snippet. For example, take a gander at XUL/toolbar:
Plain old snippet:
« XUL Reference home [ Examples | Attributes | Properties | Methods | Related ] A container which typically contains a row of buttons. It is a type of box that defaults to horizontal orientation. …
Smart snippet:
A container which typically contains a row of buttons. It is a type of box that defaults to horizontal orientation. …
We produce a sometimes over-zealous smart snippet. If you were to keep reading both of those snippets, you would notice that the smart snippet eats a bit that the non-smart-snippet does not. That is because the smart snippet is based on looking at a version of the snippet which has HTML tags in it, and then it tries to nuke those HTML tags out of existence using simple regexps.
Implementation notes:
This probably should work on other deki wikis if so adapted, but I don’t use any others, so YMMV.
We actually issue two search queries because there are two result formats that can be produced. “xml” is an inexplicable mixture of too much data and too little data. Namely, it does not tell you the tags on a document, which is basically the most useful piece of info, but it does tell you every link to and from that page (which we expose, although I doubt it will be useful enough to justify it). It does give you a link to be able to get the tags, but that’s a costly operation when you have to perform it for each search result. In contrast, “search” gives you the tags; they are only space-delimited, but that’s fine. (”Inexplicable” may be a bit harsh; looking at the source, it’s just dumping the page info without further processing/lookups, but arguably it would be very useful if they made the effort to fetch that data.)
Because of cross-site XHR issues, this is not quite as hackable as I would like. My demo server above is using mod_proxy (with a very specific constraint) to proxy the search to DevMo. When I develop locally, I have to do the same thing. Presumably if you are using Firefox 3.5 and devmo is set up correctly, then this would not be a problem. But, 1) for no good reason, I only use Firefox 3.0 and 2) have no clue whether devmo is emitting the headers that would enable that to work. I strongly encourage someone to look into #2 and fix it if not.
As with BugXhibit, the sliders are totally broken for me and it’s sad, but I left them in there in the hopes that they work for someone, somewhere. Alternately, I would not complain if someone, somewhere, fixed them.
Part of the housecleaning I am doing in the Thunderbird area of the Mozilla Developer Center requires searching out and linking up orphan pages. Sheppy showed me a trick for listing all the sub-pages beneath a specified page:
{{wiki.tree("path to root")}}
So, for example, to list all the pages under the “en/Extensions/Thunderbird” page, I embed the following template in any page:
{{wiki.tree("en/Extensions/Thunderbird")}}
When the page is published, it shows a list of hyperlinked page titles.
You could use this template to create a table of contents of sub-pages. However, the content structure on MDC seems to be generally fairly flat, so it would only be useful if you had deliberately structured pages into a meaningful hierarchy. As a tool for finding buried treasure, though, it works great!
Some of you may have already seen this on Jen’s documentation blog. For the last couple of weeks I have been finding the odd few minutes here and there to write some documentation on the address book interfaces and examples of how to use them. I’m hoping this will be useful to extension developers upgrading or writing extensions to Thunderbird 3.
The documentation and examples aren’t as extensive as the could be, but hopefully will give some useful starting points. If there’s something you think is missing, please add it to the page (or the talk page if you don’t know the solution) and help us improve it for everyone.
I know it has sorta been done before (found via Bugzilla Fixup Wiki Page on a comment by faaborg), and I feel like there has to be another live version somewhere, but here we are. BugXhibit is an MITSIMILEExhibit widget fronting a bugzilla.mozilla.org quicksearch query.
Go visit the hg repo. Or just download the source from the previous link. Please improve! (See the SIMILE Exhibit docs for how to do that. It’s all really easy.)
Notes:
This uses bugzilla’s ctype=js for buglist.cgi. It apparently has been around since 2003 (bug)! And thanks to Gerv! Perhaps not too surprisingly, the format of the results is not inert JSON but live JS code that builds a would-be-Array where each bug’s info is stored in an array. What each element in the array stands for cannot be known from the results. I find that using ctype=csv is a good way to get the headers. Rather than doing that every time (cost concerns on the redundant query), I did it once for columnlist=all (which we always use) and stashed it in bugxhibit.js. This is dangerous because it is brittle; if you try and use bugxhibit against a saved search someone made public, I at least got many fewer columns (despite columnlist=all), and things just don’t match. Not to mention there is a “cf_blocking_fennec” flag in there that I feel like should not be there.
It looks pretty easy to have bugzilla produce more sane JSON output via a template (although the security code that logs you out for a js request still should run, so don’t forget buglist.cgi.)
Even with all columns exposed when using buglist.cgi, there are lots of interesting things that are not exposed. For example, flags are not exposed via buglist.cgi, so faceting on whether things are blockers or wanted can’t be done. Once you know the bug numbers from the query, you can obviously go fetch additional information, though I think that currently still needs to be XML format, but that’s not that hard.
The code is friendly and splits up the whiteboard and keyword things so it does what you would expect and is not stupid.
I made sliders for patch count and votes. They don’t work for me anymore, and I see XUL wrapper anger (on Firefox 3.0.x), so, uh, don’t be surprised if they fall down.
The UI obviously sucks. But it’s a proof of concept, and you are the internet! You can do anything!
The comm-central tree currently includes an extension that is known as Palm Sync and provides address book synchronisation support with Palm devices. The extension was shipped with SeaMonkey 1.1 and there was a version posted on addons.mozilla.org for Thunderbird 2 but that version isn’t available on AMO anymore.
It has become clear that maintaining the Palm Sync extensions doesn’t make sense to do in-tree any more, because the work/benefit ratio is too low. Specifically:
There is no active maintainer for the Palm Sync extension, meaning that the work of maintaining it falls on people who should be spending as much of their time as possible making the entire platform better.
Palm Sync is a binary extension, closely linked to the TB sources. Due to the close linking, if we re-factor how the address book works (even the internal workings of contacts), we have to do work to update palm sync. This wouldn’t be too bad, except that palm sync requires a special version CDK to build it, and then there isn’t an easy way for developers to test it without palm devices. Whilst we could buy these we’d have to make sure that any address book developer had access to one, or rely on one or two people testing patches etc.
From a forward-looking point of view, we want to be able to expand the possibilities for device synchronisation. The palm sync code, unfortunately, is very specific to the palm sync interface, and we believe it is not a suitable base for that to happen. In-between times, we want to be moving forward various areas of the address book and improving it for users. Trying to maintain Palm Sync alongside that, I believe, will slow us down.
Therefore we have taken the decision to drop palm sync support from comm-central. We will be archiving the code in its current state, and if anyone would like to take it over and maintain it, I will be happy to provide support to get them set up (once we’ve archived it I’ll update this post with the archive location) - just drop me a line.
My bus ride home trippled in time last night because of some construction so I had the opportunity to watch this TED talk.
This really drove home the power of defaults in user interface choices and how it is the responsibility of good designers to default to the right behaviour, especially when the options are complex.
If you develop for the mozilla platform, you might be used to error messages like the above. (Or you might wish you got error messages like the above…) An uncaught javascript exception has resulted in a message in the error console as well as some equivalent stdout spew because it’s a debug build. While any error is better than no error, it doesn’t exactly narrow down how we got there.
Wouldn’t it be nice if we got back-traces for these errors?
The future is now, people! And it comes in the convenient form of a patch against the 1.9.1 branch, just like you always dreamed! Also, an extension.
Currently (pre-patch), there are basically 3 ways scripting errors can show up in the platform:
nsIScriptError instances. These are what show up on the error console. These have information equivalent to a single stack frame.
nsIException instances. These can provide a stack in the form of an nsIStackFrame chain (the same thing Components.stack gives you). These get converted into nsIScriptError instances when it comes time to report them to the error console. From a stack perspective, only XPConnect produces nsIException instances with stack traces, although you can make your own via Components.Exception. A fundamental limitation of these stack traces is that they are only constructed from live JS call stacks, so if a JS exception has unwrapped its way to the top-level you are out of luck.
JavaScript Error instances. These have a private super-rich (it even knows arguments!) call-stack that can only be exposed as a string via the non-standard stack attribute. XPConnect understands JS error reports (the ‘flat’ mechanism by which SpiderMonkey reports errors/exceptions to C++ code), but it has no clue about exceptions and their Error form of existence. The exceptions in their error report guise are converted into nsIScriptError instances.
Introduce an nsIScriptErrorEx interface that extends nsIScriptError to provide a ‘location’ attribute like nsIException which is an nsIStackFrame.
Modify nsScriptError to implement the extended nsIScriptErrorEx. Alternatively, I could have made XPConnect’s nsXPCException class implement nsIScriptError or nsScriptError also implement nsIException or something like that and not introduced nsIScriptErrorEx at all.
Modify all nsIScriptError-creation sites that I care about (I’m not looking at you, DOM workers) to try and provide or propagate existing nsIStackFrame information.
If a JS stack frame is not available, but an exception is in the form of a JS error, suck the call stack out of it. Theoretically, this should not be a fallback but rather the default case, but it depends on some JS/XPConnect implementation details I am trying to avoid finding out about for now.
Modify the JS API to provide call stack sucking functionality.
Does various sketchy things to expose XPCJSStack::CreateStack from XPConnect to the error reporters in other modules. If you thought the choice of creating nsIScriptErrorEx was sketchy, welcome to the Downtown East Side of dubious patches. I expect there is no chance of it working on Windows because of this, and you may be out of luck on OS X. Behold your comeuppance, popular platforms!
Add an nsIConsoleListener at app-startup that is aware of nsIScriptErrorEx and knows how to generate totally wicked 256-color ANSI escape sequences.
Not expose the stack traces in the error console. The error console is for suckers who don’t have impossibly fast reflexes and a love of XON/XOFF flow control.
Only target Thunderbird. Behold your comeuppance, all other mozilla applications! (The extension wizard didn’t know how to do the thing that makes it work on all xulrunner-based things… feel free to push a fixed install.rdf to my repo.)
I have logged bug 493414 to hold the patch and hopefully track the effort moving forward.
Exciting Vancouver news! Mayor Robertson has put forth a motion for city council to vote on next week which is chock full of amazing words, and which passed, will direct the city to have a bias towards openness — open source software, open standards, and open data.
That’s pretty impressive! If the motion passes (which it should, riding on a global wave of sentiment towards openness, and fitting in with the platform that got seven of the councilors elected), this could mean great things for Vancouver, especially at the intersection of software, business, and the public.
On the issue of open source, I would love to show that local governments are able to recognize the strategic and control advantages inherent in software that they can influence and modify, and help push back the fear-driven campaigns which bias towards monopolies at taxpayer expense. Similarly, promoting the use of open standards is a no-brainer that the best technocrats realize can give them the power that befits them as customers. These ideas have been well articulated globally over the last few years, and I would hope that all high-level government staff and officials are briefed on the topics by now. (If any local officials want to discuss this in greater detail, there are many qualified experts in Vancouver, don’t be afraid to ask for names or opinions!).
Open data is a more recent concept, the implications of which are likely as important as the rise of the web. With open data, governments have a unique opportunity to create economic growth, reduce operating costs, and enrich the life of their constituencies, simply by making a policy decision such as the one in tuesday’s motion, and following through.
As Sir Tim Berners-Lee (the creator of the web) discusses in this 15-minute TED talk, the simple act of releasing public data enables others to create value. Of course, as the motion indicates, personal privacy rights trump, and we don’t want to release data on individual citizens — luckily that’s not needed in order to enable value creation. As an example, this impressive screencast of Wolfram Alpha demonstrates the power of new computational platforms leveraging public data. Vancouver’s data belongs there.
Most government data is public data by definition. What’s compelling about open data in the age of the web isn’t the fact that citizens have access to such data — they typically have the legal right to obtain it through administrative requests, even though those are inconvenient (and very expensive for the city). What’s compelling is that by making what belongs to the public available via the web, the city can accomplish many laudable goals at once:
In many cases, simply enabling self-service on the web will reduce costs for the city and provide better service to its citizens.
By making data that it doesn’t have time to process and analyze available, the city allows others with time and expertise to do such analysis with no cost to the city. This will sound unbelievable to bureaucrats unused to open source, but this kind of thing really happens. You can’t predict who will do what with what data, but you can be sure that it can’t happen unless and until the data is available.
Some of those activities will just be interesting. But some will create new businesses, or allow existing businesses to become more efficient. What if local retailers could access demographic trend data for free on the web, today? What if companies outside of Vancouver could get a deeper understanding of Vancouver simply by looking at the data? Everyone knows that Vancouver is a great place to live. The city’s economic strengths are not as well advertised. Enabling an ecosystem of people who turn data into interesting, insightful, and useful applications and sites can only help. Think of open data as the infrastructure of a chamber of commerce 2.0.
The city is there to serve the citizenry. To the extent that it is the caretaker of public data, and that the public has good ideas for using it, its job should be to get out of the way. Part of being a transparent government is to be invisible — to not get in the way of experimentation and innovation. Promoting open data while preserving privacy feels like a great goal for the city’s IT staff.
There are also intangible benefits that come from these kinds of attitudinal shifts in how the city relates to the internet and the software economy. From a recruitment point of view in the software industry in particular, a city which embraced openness and the internet would be that much more attractive to the kinds of technical, creative, and public-spirited individuals that I seek.
Finally, local technology leaders are that much more likely to engage with the city and provide their help. I know that the notion of an “Open Vancouver” makes me much more keen to engage with the city, as it would put the city on the short but growing list of governments who understand how they can leverage the web and openness to improve life for their constituencies.
One of my first jobs in IT was as a “computer consultant” for my university. I got to learn a lot about computers of various kinds (including currently useless but still formative bits like writing REXX programs on a CP/CMS IBM 3090 mainframe), and, more importantly, I learned a lot about what it takes to really help people solve computer problems. We had all the kinds of users you’d expect in a decent-sized community: haughty faculty (and haughtier grad students, for some reason), who absolutely demanded that you stop whatever you were doing to help them fix their margins <em>right now</em>. We had to mediate between first-year students lost and confused in their first exposure to the net, and technical staff who were straining under the onslaught of the first week of classes.
Still, it was a lot of fun — we had autonomy to decide what problems were worthy of paper handouts, to hand out as answers to FAQs — we had special accounts with free access to the high-resolution printers — but most of all, we had lots of interactions daily with people who were truly grateful for the help we provided. Not all interactions were positive, but the vast majority of them were. There was a real community between the student staff, the full-time staff, and the avid users who spent their days in the computer center working on their papers, homework, and assignments.
The job
These memories come back as we’re now looking for someone to help coordinate Thunderbird’s technical support communities. The challenge is orders of magnitude harder, but the opportunities to help are equally huge.
Mountain Lion Safety by ekai on flickr (helpful, no?)
It’s become clear to me that this job is fairly unique, both in scope, and in what we’re looking for. The right candidate will have a rare blend of empathy & technical knowledge, clear organization skills. She or he must have the ability to bring people off the ledge, recognize and encourage peer leaders, but also know how to deal with poisonous people. This requires both clarity of thought and clear, efficient expression. Our ideal candidate knows Thunderbird well, but most importantly can understand both the requirements of providing technical support for hugely diverse populations of users, who often come for help when they have critical issues that are often caused by external actors like email providers. A hard job to fill.
A big part of the job is also to understand the existing bits of the existing world of Thunderbird support, and figure out ways of connecting the bits that work, and building new bits if needed. From where I’m standing, this ecosystem includes forums like mozillazine, which have garnered huge numbers of posts with very valuable information, but which don’t necessarily provide the best experience for novices. It also includes the GetSatisfaction forums, which provide a lower barrier-to-entry for many users, but which are still in their infancy, both in terms of content and in terms of people providing answers. The ecosystem also importantly includes SUMO, which right now is focused on Firefox, but which could hopefully be deployed for Thunderbird use someday. A comprehensive solution also likely involves figuring out how to help people over Twitter, on Facebook, or wherever Thunderbird users are likely to look for answers or express frustrations. Whoever gets this job will end up diving deep into the world of Mozilla support overall, and learn from all of the people who’ve built those foundations — then build upon them.
As the central point of contact for support issues, this person will be incredibly helpful in working with the QA and dev teams to prioritize bugs and other issues, so that the next revisions of Thunderbird or Thunderbird websites work better for more people. Finally, it would be great to coordinate with the support micro-communities that exist around the world. In general, the job is clear: help people with Thunderbird, and help people help each other.
If this sounds like you, send us an email, explaining why you’re the right person for the job.
I always advocate against simple (and especially modal) dialogs in user interfaces because they aren’t there to help the user get past the problem, more like work through the emotional issues the software is having.
Dialogs aren’t the real evil, though they usually aren’t great, it’s the lack of real negotiation. In the book Getting to Yes it states that you “Make emotions explicit and acknowledge them as legitimate…”, however don’t stop there.
A useful dialog would negotiate with your users. Give them actions and power to change their situation. Don’t ask users to acknowledge your troubles and stop the negotiation there. Reconnect! Try Again! Even simple actions can help people correct the situation.
This upcoming Thursday the QA team of Thunderbird is organizing a Linux Bug day - we will try to target and add information to bugs that affect the linux platform. With the help of packages maintainers from Fedora, OpenSuse and Ubuntu, people using these distribution will be able to install a nightly build of Thunderbird using the systems package management tools. The bugs that we would like people to comment on are in the UNCO state - meaning - they need more information (crash stats, steps to reproduce, etc ...) for to be able to be fixed by the developers.
How do you make the dualbutton always appear like the last two sets of screenshots (as it does on hover)?
I’m looking to make dualbuttons always show their dropdown button with a real button like look. This dualbutton reply button is going to land in Thunderbird 3 soon and I’d like the style to look correct for both Linux and Windows (Mac is using its own button style).
However this doesn’t appear to be some kind of toolkit CSS hover issue. The windows CSS is decidedly worse than the Linux right now so that may be a separate issue all together; and if so we can attempt that in the same way we handled the Mac.
Hints, answers, and the like are greatly appreciated in the comments.
In the coming week, there will be 2 buildbot maintenance windows that could close the tree for 2-4 hours each. The reason for these is to allow for distruptive (from tree green-ness point of view) build systems and buildbot changes.
After these, the new hardware and resources available to our build infrastructure should be ready for use. As usual, work on these will be tracked in bugzilla, and if you encounter any problems, or have any good reason why this should be postponed, let it be known.
9AM PST, Monday, May 11th, 2009 - bug 492298 9AM PST, Thursday, May 14th, 2009 - bug 492297
[Edited: Fixed incorrect times due to backwards EDT -> PST conversion]
Thunderbird knows a lot about your email. After all, it’s got access to large amounts of data, and builds sophisticated databases so that it can be very responsive, even when dealing with large folders containing thousands of messages. Wouldn’t it be nice if we could use this information to extract either faster workflow, or even insight into our email habits?
On Tuesday, as he was slogging through some somewhat antique code in the front-end of Thunderbird, Andrew asked whether Thunderbird’s “start page” was what we wanted it to be, which is Andrew-speak for “this is broken, we should fix it”. We’d actually discussed what to do with that page for a long time, but had focused on other, more infrastructure bits for a while. I decided it was time to dust off those plans, and see what we could do.
First, some background. The “start page”, which makes a lot of sense in Firefox, never made a huge amount of sense to me in Thunderbird. In particular, it’s shown only when a folder is selected, and no message is selected. That’s hardly a logical time to show the (colorful, pretty, but fairly useless) page we show now. Instead, why not show information about the selected folder, and help people who clearly intended to select a folder, so most likely wanted to do something related to that folder!
We could still use a small part of the pane to display interesting news snippets, as a way of keeping users aware of new developments, such as new add-ons that we want to promote, or Mozilla events. In fact, by making that page useful, we’re more likely to get people to read a sentence or two which might change periodically, as opposed to changing a page that is so big, wordy and useless, that I suspect most users are completely blind to it.
A couple of days later, we have an early patch, which feels pretty compelling to me:
It summarizes critical data about the folder (name, number of messages, number of unread messages);
if you were recently reading that folder, it points out the last message you were reading, so you can quickly find it again;
it shows you a few of the messages that are most likely of interest (because they’re unread or starred);
and finally it gives some information about the activity in the folder: a histogram showing activity over the last 52 weeks, and most prolific authors and most active threads during that same period.
For example:
The icing on the cake is that if you hover over an author or a thread title, it will highlight when those messages occurred in the histogram (in this case, the “An alternate take on HTML 5″ thread). Readers of m.d.platform won’t be surprised at any of the names that show up above!
There are lots of possible additions: Some of the ones we’ve thought of include:
showing how much disk space is used by the folder
showing the “largest” messages
showing the status of autosync/indexing jobs
Note: this hasn’t been through a visual design phase yet — the look will change, once someone who knows what they’re doing has a chance to make it nicer! There’s also a lot of work to do to make sure that it does the right thing for saved searches, smart folders, etc. And yes, we’ll make it optional, just like the start page is now.
I’ve been playing with it for only a little bit, and it’s fascinating how interesting it is to get some data on one’s email. For example, I more-or-less follow a small-inbox model, where emails don’t stay in my inbox if I can avoid it — they get deleted, or archived. As a result, the sparkline for my inbox is:
which isn’t as short as it should be, telling me pretty quickly that I have some old messages that need attention. It’ll be interesting to see what else we learn from these kinds of simple personal analytics.
What other kinds of visualizations, summaries, and analysis would you like to see in Thunderbird, or in add-ons?
[Update]: I liked the idea that a commenter suggested of showing what tags were in use in the folder, so I had some fun, first with a “tagpie”, which proved mostly useless, just like most piecharts; then with a “tagdots” small-multiples visualization:
I don’t think the tagpie is worth keeping, but the dots are tempting. As an aside, the Protovis library really is as easy to use as I’d hoped.
There’s been a few changes around comm-central’s automated testing recently that I’ve been meaning to post about.
The most important changes to note are:
make check now only runs the compiled-code unit tests (we only have two of these in mailnews).
make xpcshell-tests now runs the xpcshell tests that were previously run as part of make check. I have just checked in the patch which means you can now do make -C objdir/mailnews xpcshell-tests like you could with the check command before.
The check-one and check-interactive commands remain the same.
The xpcshell-tests also now have shutdown leak statistics enabled. Unfortunately for mailnews we currently have a lot of leaks due to our test harness (which provides a consistent profile directory that isn’t the build directory and a few other things). We’re currently not cleaning the test harness leaks up as this would break check-interactive - a useful tool to developers. Hopefully this will be fixed soon (patch in review) and then we can tidy up our leak logs.
Since I happen to have some downtime thanks to the short space between college and a summer job, and some spare time with four wisdom teeth newly missing from my mouth, I have returned to work on jshydra. I am in the midst of simplifying the build structure for new or non-Mozilla hackers, and am also patching up one of the main scripts I have, the documentation-association script.
On Monday, May 11, 2008, at 1:00 PM EDT (10:00 AM PDT, or 1700 UTC), I will be holding in the #static IRC room for the benefit of users a "learn jshydra" day. You may of course ask me questions any time I'm actually on IRC (nick: jcranmer or derivatives thereof).
I hope to finish up the build structure by then and get a wiki article on the topic started as well. A feature request list is already starting, including the ability to take JS out from an HTML file. If you have others, communicate it to me somehow, and I'll stick it somewhere where I can remember it.
We have three computers, a Mac Mini, a MacBook, and a Dell laptop. Last year the hard drives on both Mac products failed. This year the hard drive on the Dell laptop failed and there was also an issue with the monitor and so the motherboard had to be replaced.
For both the Mac Mini and the MacBook, I was able to go to the Apple Store, make a reservation, and then drop off my computer and it was fixed. There were a couple of hitches but otherwise, we got new hard drives in both machines and that was it. The process was very smooth — and it needs to be when customers pay extra for Apple care/extended warranty and when products fail (and customers are mad and frustrated).
What I really liked were the people (knew what they were doing), the ability to schedule an appointment, and the ability to just hand it off and have someone fix it — “here, fix it”.
The Dell experiences were the same. Dell provides a nice piece of paper that has your order number and the support phone numbers. I called about the first issue re: the hard drive. It got to the point where I was talking to a higher level support technician that walked me through removing my hard drive, send it back, and install the new one.
What I really like here was that they were able to trouble shoot quickly, send me to the right person, and that person recognized that I was able to go ahead and remove the hard drive and follow other slightly more technical instructions.
The Dell experience with the motherboard replacement was even better. We called Dell. A technician that Dell outsources to came to the house (on time) and disassembled the laptop and installed a new motherboard. This was another “here, fix it”. He was done in 30 minutes and the laptop is running smoothly. I asked him if his company did software support. He told me that they didn’t because software issues can take 5 minutes or a whole day or two (which I already knew).
What I really like here is likely to be clear. A support technician from Dell came over to the house (much like a plumber or electrician) and fixed what was broken.
Last Wednesday morning (in the EDT timezone that I go to school in), I took my final in Probability & Statistics. It was a moment that I didn't think too much about until this morning, when, in one of the newsgroups I frequent, there was a discussion as to how much faster one option was compared to another. This post come up:
A good idea would be to measure each iteration separately and then discard outliers by e.g. discarding those that exceed the abs diff between the mean and the stddev.
I leave it as an exercise to the reader to figure out why that's not a good idea. In any case, the last unit of the class dealt with the fun part of statistics, which is to actually evaluate whether observed data is statistically significant. The actual math involved isn't too bad, assuming you have someone spit out a cumulative distribution function for the t-distribution for you (here is Boost's code), but it's a bit convoluted to write here, so read Wikipedia's page. The correct tests are actually the two-sampled t-tests.
But I got to thinking. One thing I've wanted to see for a while is a profiling extension, one that would run some JS code snippet multiple times and produce various reports on profiling runs. Wouldn't it be nice if such an extension could compare two runs and determine if they was a statistically significant difference between them?
It took a little longer than initially planned for, but it's finally complete. All our hardware is now sitting in our brand new space, with room to grow.
The hardware upgrade also went really well, so our overall build capacity has been greatly increased today.
The builders are just starting to pick up builds again, so I expect it will take a little bit more time for the trees to go green again.
Robert’s recent post about the acid tests on wikipedia reminded me that I’ve been meaning to post about Thunderbird and the acid tests for a few months now.
Sometime last year there was a discussion on the results of Acid tests in Thunderbird. Whilst Acid3 was a similar result to the equivalent Firefox build, Acid2 was much worse - this was strange given that Thunderbird runs on virtually the same Gecko engine that Firefox does.
A bug was duly filed, after a bit of investigation, it was found that there were two issues: 1) Thunderbird denied access to load data URIs, 2) Thunderbird needed plugins enabling (plugin loading is disabled by default to help protect users against detection of reading by loading remote data, and potentially other reasons I don’t know about at this time).
We then fixed the content policy so that we enabled the data URIs. Using today’s nightly builds (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090429...), here is Acid 2 in Firefox (left) and Thunderbird (right):
Additionally Thunderbird passes the Acid 3 test to very nearly the same extent as Firefox:
The difference here is the “Linktest Failed” - as Thunderbird isn’t a browser, we don’t enable history on links (they don’t turn a different colour when you click on them). You can see this effect of the “Linktest Failed” in Firefox’s private browsing mode.
For both these tests, all I changed from the default set up was to set the preference mailnews.message_display.allow.plugins to true. To load the web page, I set Thunderbird’s start page to the appropriate Acid 2 or Acid 3 URL and then selected Go -> Mail Start Page.
This is both good for Thunderbird - basing ourselves on Gecko means we don’t have to worry too much about laying out what we display - and for extensions - authors can know they can load pages/render content in Thunderbird and they will come out the same as Firefox.
On Thursday, April 30th, 2009, we will be moving all our gear to a different location, so there will be downtime of all Mozilla Messaging services spread through the day.
Internet facing services should be down for 1-2 hours, and these include:
www.mozillamessaging.com
planet.mozillamessaging.com
SpreadThunderbird
All other *.mozillamessaging.com sites
Build services will be down for a longer period of time, and it might require closing the tree for a few additionnal hours, while it gets itself back to it's usual green.
As a positive side-effect of this move, we'll have more room to expand our capacity in the future. Plus, this includes a planned series of hardware upgrades that will be happening at the same time, a perfect occasion, since we have to power everything down anyways.
When completed, our build infrastructure will have close to 4x more computing resources at its disposal, yummy!
More information will be posted to this blog, as the move progresses.
Also, you can track progress on this issue by watching bug 490578
As usual, we always try and minimize outwardly visible downtime, but this time around, it can't be completely avoided.
Since last Friday, auto-configuration as been enabled in Thunderbird nightlies. This means that configuring an email account will just be - in most cases - your email , your password and your name and Thunderbird is going to "guess" the settings. Sometimes guessing works - sometimes it does not. When it does not we get the information from a list that we maintain. Unfortunately we can't have account for all Internet service providers all over the world - this is why I'm writing all this, you can help us by making the list bigger, adding your ISP will help (especially with security settings for authentication.) Instructions and list are editable.
The primary Mozilla Colo in San Jose has experienced networking issues. While this was hapenning, there was some spurious build bustage, as various services *.mozilla.org would sometimes timeout.
[Update: Mon Apr 27 10:13:59 PDT 2009: All is back to normal] [Reported: Mon Apr 27 08:45:37 PDT 2009]
The Thunderbird developers have decided that there are enough blockers that aren't going to make it by tomorrow that beta3 (and therefore the string freeze as well) will have to be slipped by some number of weeks. By how many weeks is currently unclear. We'll hopefully know more within the next several days and expect to have a proposal soon...
A few weeks ago in mid-March we came across a fix (for bug 483629) that changed an existing string without changing the entity name. Instead of fixing that, we opted for going into the direction of fixing all the strings in
properly and get rid of all the magic numbers that posed as entity names (and remove some obsolete strings in the process as well). Fortunately that work has now been completed by Kent James and the fix for bug 484147 was landed a few days ago.
What this means for new localizers is, that the entity names are now much more self-explaining than they were before. However for existing localizers this means, that a lot of new strings have shown up, which you will now have to tackle again. We believe that this is the right solution for the reasons outlined above.
So the release date for Thunderbird 3.0b3 the last beta of Thunderbird 3.0 is approaching. This means that features are landing, and that we need to make sure that everything works correctly. To do so two things need to happen, first the new features needs to be tested on a broader scale than the development team can do (more hardware combination, servers combination, more extensions etc ... ) and at the same time nothing else should regress.
To achieve the first task - we have organized a Testday. It's a day where we invite everybody to test the new features recently added to Thunderbird. Why do we do it on a specific day ? It's easy to gather people on one day. It's easier to give people interested in joining the test effort information on what's new, how to test the new features and describe them. It's also a great way to have different people testing the same part to talk to one another. We traditionally do that on irc on #bugday. I think the communication while testing is important for at least two things - it helps you get the help of other people if you are having some issues while testing. It might help you file your first bug - if you are unsure of things just ask some people will be glad to help. As a way to communicate more efficiently, mozillamessaging as setup a web base chat, if you don't want to use irc just point you browser to chat.mozillamessaging.com and talk to us there.
Thursday April the 23rd 2009 is the day where the new features are going to be tested. Information on what will be theres to be tested is visible here.
To make sure that Thunderbird 3.0b3 will be of the highest quality available we will also run a series of tests, that have been run for alpha1 and for beta2. We don't organize an event for that - because it takes much more time to do regression testing than testing the new features. To participate to this testing you will need an account on litmus, some time, and a build dated from the 28th of April 2009. To test you need to point your browser here, and decide which of the tests you want to run, read the instructions to run the test and report the results from your run. If the test is not clear - say so , so we can try to make the test clearer. If the test does not pass, meaning you have found a bug, please make sure to create a bug in bugzilla. Not creating the issue in bugzilla means that the testing you have done is going to be lost .
Thanks in advance for the time you are going to spend to make Thunderbird a great quality product.
The Thunderbird quality assurance team is most of the time available on irc, so if you have question just come and ask. As stated above the web based chat is an experiment.
One of the features we wanted in Instantbird 0.2 was the ability to install libpurple protocol plugins like any other addon. I'm happy to report that this is now possible with current nightly builds.
This file contains a binary module compiled for Windows, Linux and Mac OS X (universal), produced by copying the code from here into the Instantbird source tree. This is the quickest way I found to build it, we will need to figure out a better (without having to download and build the whole Instantbird source code) way later. This is the exact patch I used to build it.
The xpi file also contains a set of icons and a locale file. I will explain in another post how we replaced the usage of gettext in libpurple by a way to get localized strings from regular .properties files.
Feel free to try this facebook chat addons. I don't know how stable it is, but I've used it for a few days already and haven't encountered any serious issue. If this turns out to be crashy for you, don't hesitate to send us crash reports, I uploaded the symbols to our symbol servers, so the reports should provide useful information.
I have other nearly-ready Instantbird 0.2 features to introduce in more details later, including: localization, emoticon themes, message styles (like Adium), ...
Next time: how localization works with Instantbird and how we replaced gettext.
Starting at around 8:30 EST this morning, our main firewall has started experiencing some problems, and as a result, network connectivity is degraded. I am seeing highly variable packet drop rates, sometimes reaching up to > 80 %.
This means that currently, pretty much all *.mozillamessaging.com and *.spreadthunderbird.com will be slow at best, and might display hangs and time-outs.
Apologies all around, and I'll post an update as soon as this situation is resolved.
[UPDATE: 17:05 EDT - Issue resolved] [UPDATE: 13:15 EDT - It's hapenning again] [UPDATE: 11:20 EDT - Things are looking normal again]
There's been a slight change of plans for the Thunderbird 3 beta3 release. The release schedule has been pushed back a week. That means that the new release schedule is now (All dates use time of 23:59 PST - l10n-relevant dates are bold):
[I wanted to post this on my Wordpress.com blog,
but they seem to strip out <video> tags (i.e. I don't see
them being shown when I click Preview, but it does on self-hosted
Rumbling Edge). Oh well.]
CS3108 has ended for the semester, here are the presentations.
Again, great effort shown by them, I hope they continue to achieve
greater stuff in the future!
Yesterday, Reed helpfully enabled the NEW -> UNCO transition in Mozilla's bugzilla installation, which will enable us to reverse some mistaken decisions in the past. Looking at the current list of bugs, we have way too many NEW bugs to be healthy (Five thousand three hundred eighty-five, to be precise, at this time of writing).
So please help us triage our components by finding NEW bugs that do not have clear steps to reproduce and unconfirming them. While you're at it, you might want to try to do other triage on the bugs.
As some of you might have noticed last week, the Quality Team (Wayne, Gary, Joshua, Wada, Magnus, Phil, Hansen, and a few others (and I'm sorry that I forgot your names)) of Mozilla Thunderbird is celebrating one year of bugdays. Last year as been amazing as the bug database for Thunderbird as been cleaned up a lot (that database is accessible to anyone at https://bugzilla.mozilla.org).
In order to celebrate we've setup a nice deal for you, if you comment on two bugs , or change status on two bugs - The idea is to revive bugs that have not been active for some time now. Once you've done that come to the #tb-qa irc channel on irc.mozilla.org, and give us the bug number you would like us to have a better look at, and we will make our best the bug gets in the state were it can get fixed by the developers. We are providing list of bugs and hints on how to join and do it at https://wiki.mozilla.org/Thunderbird:QA_TestDay:2009-04-02
The Thunderbird developers have finalized the release schedule for Thunderbird beta3. Here it is (All dates use time of 23:59 PST - l10n-relevant dates are bold):
We’ve recently moved the Mozilla Messaging offices, for a variety of reasons, to our cool new digs. Partially so I have something to look back in a few months, I thought I’d write down my thoughts about the new space and neighborhood.
Mozilla Messaging Office (credit: Mark Surman on flickr)
The office itself is pretty much what I was hoping it would be. It’s much bigger than the old space, which means we can continue to all be together, for the vibe that it generates, and to facilitate communication. It’s even big enough for Bryan’s Love Sac, which is a huge draw for visiting kids and executive directors. The internet service rocks, especially compared to the ISPs wetried at the old place. (it’s a fascinating world when residential internet service is head and shoulders above what you can get in an office tower). We have still to install some more lights and another desk or so, but there’s no rush. There are some definite oddities to the space, like the bathtub in the open space, Andrew’s laser and fog machine, but I’m sure we’ll find interesting uses for all of that. It’s been also really easy to have peoplestopbyandhangout, which I think helps us build connections with other Mozilla folks, other Vancouver tech, design, & open source people. Some of that was a bit awkward in our previous space.
Miniature Downtown Eastside (credit: joannaforever on flickr)
What is more interesting than all that “inside” stuff, though, is the neighborhood outside. For people not familiar with Vancouver, we’re located in the “notorious” downtown east side — a weird neighborhood with its own unpronounceable acronym: DTES. It’s a neighborhood with a long history, much of which I don’t know, and for much of the recent decades, not very healthy. It’s easy to simplistically describe it as skid row, which is certainly part of the truth. In particular, if you look at how the press covers it, it might seem a bizarre place to choose for an an office. A center of chronic drug use, the place where people go when they can’t go any lower, a money-pit for well-intentioned but ineffective social programs, all the headlines are bad.
If you go past the headlines and read the globe and mail reports, and more importantly, if you spend a bit of time here, the picture gets far more complex. I know I don’t know nearly enough about the social crisis to pontificate about it. All I can report are my impressions after a few days.
six lives (credit: SqueakyMarmot on flickr)
The first impression clearly centers on “the people in the street”. During the lunch hour in particular, the number of people idle in the streets is stunning. In most of Vancouver, like in most healthy cities, the people you see in the street are going somewhere — they have a place to go, something to do (the few stationary folks are usually smokers escaping the no-smoking rules, and geeks wondering where to go for lunch). Around here, the number of people who just seem to hang out with nothing to do is startling. It’s expected and undeniable that there’s despair, sorrow, drugs, and mental illness in these streets. But what I didn’t expect was to see this much idleness and boredom, states which my friend Jen correctly characterized as toxic. The ill-informed manager in me feels that part of the answer has to be identifying some activities that “these people” could do which would give some energy and impetus for action in their lives. Then I realize I have no idea what I’m talking about and keep moving.
Woodward project (credit: Beach650 on flickr)
The second recurring thought is that this world is possibly about to change radically. First, because Vancouver is a city with a growing population and a fixed size (there’s water almost all around), and this kind of economic black hole feels unstable. More specifically, there are some developments that I wouldn’t be surprised to see push the economics past a tipping point. The Woodward’s project is a huge tower about to accept tenants, which will include 536 condo units, a university campus, a grocery store, a bank, etc. People sometimes focus on the 40% of those condos that will be below-market (i.e. subsidized) housing. Those units will likely help relieve some pain, but I doubt the people sleeping on the street will qualify. I’m predicting more change from the influx of people to the market-priced units, the university, and other businesses that move into that building (and likely the neighboring buildings, whose property value will likely rise). All of the demographics will change (age, income, race, health, etc.), which I expect (and hope) will change the feel of the neighborhood. A thousand students means a lot of young, healthy, ambitious and optimistic people in the streets, faced with a situation that needs people as much as it needs money. People with incomes and property will mean more people who care directly about the neighborhood.
The Irish Heather (credit: urbanmixer on flickr)
The third thought is that the street scene you get at first glance is highly misleading. The restaurant scene, for example, is nothing if not high end. Across the street is Boneta, which serves $79 prime rib. Around the corner, the Irish Heather and its Shebeen whisky bar in the back, has 4 columns of whiskies. The related Salty Tongue is a great place to have work lunches, and Salt is hip enough to be a tasting room, not a restaurant. Even our building houses a fancy teahouse which serves pastry flown in from my home town. More reasonably, my friend Sally told me this morning about Deacon’s Corner, a diner that’s two blocks away, so I headed out there for lunch. The place was packed with 30-somethings wolfing down burgers, all hipper and more web-two-oh than each other. Food aside (although food is crucial), if you slow down when you walk in between “scary” people, you notice that behind the glass fronts are banks of young architects hacking on laptops. That that strange storefront is actually open, and selling cool art/crafts stuff. You notice that in fact you’ve seen quite a few friends in the neighborhood, and that’s not counting the social activists. You reflect on the fact that there’s a facebook group for the building you’re in, and that their apartments all look pretty swank and nice.
This is the downtown east side?
Which brings me to the fourth thought, which is that these neighborhood labels are awfully fungible. Looking north, we’re one block away from Water Street, which is the epicenter of Gastown, “tourist central” (it’s a bit funny when some of the tourists try to explore and end up on the “wrong” street). Two blocks south and you’re in Vancouver’s older chinatown, complete with yummy cheap steam buns (thanks Avi for the rec). Three blocks west, and you’re in the no-name neighborhood with hip clothing stores and (just to bring food back in), So.cial, Brioche, Nuba, and the awesome Greedy Pig (which is itself a few blocks away from the fanciest bits of Hastings St, complete w/ Cartier & Hugo Boss stores. What this makes me feel as well is that as catastrophic as the situation is for the individuals involved, from a city planning point of view, it’s extremely punctate, unlike the sprawling suburbs of so many urban centers. Surgical, small scale interventions feel more appropriate than large scale urban renewal.
That’s likely more than enough words after just a little bit of living here. So far, I’m enjoying it all. Do come visit, I’ll take you on a tour. I have yet to try the Guiness at the Heather…
A nice Guiness sign (not in Vancouver) (credit: xb3 on flickr)
We have just released a small update to Instantbird 0.1.3. This will fix the connection issue with ICQ that appeared a little more than two weeks ago (sorry it took so long!) and improve the stability. You can download this new 0.1.3.1 release from this page or just click on the 'Check for updates' menu to download only a small update file.
We are going to post a status update about the progress of the development of the 0.2 version soon.
The Thunderbird developers are currently discussing the potential schedule for localizers for the final release of Thunderbird 3, which is currently scheduled to be released somewhere in June or July.
The main issue currently is the overall string freeze date for TB3.
We currently do not have a good feeling on how many string-related changes might still be needed for the final TB3 release. So the question basically comes down to:
"How much time do you need at a minimum before the final release date?"
But of course this question also affects all other locales, as we assume that you guys want to do a lot more internal and external QA work on your localizations than you did for the alpha or betareleases. So we'd like to hear from all other locales as well.
We'd really appreciate a broad feedback from the l10n community here. Please remember, that this is the first major release for pretty much everyone, who is currently in a leadership position in the TB community. So we really need your feedback to make a good decision.
Please direct all your feedback to the discussion of this matter in the l10n newsgroup. That will make it much easier to track all your feedback
While doing various kinds of marketing research around Mozilla development, I’ve noticed a disturbing trend, which is probably well-known to most of you: Mozillians Earning A Living Somehow (MEALS) often seem to resort to code forks. In the mailnews area, we have Spicebird and Postbox. I’m less familiar with the browser area, but Flock is a similar example. This post from lilmatt describes some of the issues for Flock, also discussed by Daniel Glazman. I was particularly intrigued by lilmatt’s comment:
“If, as an example, Flock were to be implemented as an extension and attempted to say, overwrite the affiliate tags for the search box in the chrome with it’s own to redirect revenue, I think they’d be vilified and perhaps even blocked”
This reminds me of an issue that affects microenterprise loans in developing countries, as pioneered by the Grameen Bank. Sustainability is the holy grail of any microenterprise fund - but the interest rates that must be charged for sustainability are shocking to many people, usually near 40% per year.
Sometimes a well-meaning organization will go into an area, and setup a non-sustainable microenterpise program that charges “reasonable” rates, say 10% per year, and is understanding and forgiving when their poor borrowers can’t repay the loans. That program operates for awhile, but inevitably fails. After that happens, the microenterprise community has learned that it is impossible for sustainable microenterprise operations to function in the same region, because they are “vilified” for charging “exorbitant” rates for their loans. Or the borrowers have come to believe, due to the forgiving nature of the well-intentioned organization, that loans are really gifts. This cultural pollution that was inflicted on the region by that well-intentioned organization persists for an entire generation, during which time no real, sustainable loan program can be established, and the local region is deprived of the benefits of microenterprise loan programs. (OK, this is a simplification, but I hope you get my drift.)
I’m afraid we have this kind of cultural pollution in FOSS . As I look at vertical markets, often there are virtually identical applications in both the open-source and commercial spaces. The cultural expectation is that the addon for the FOSS application (like Thunderbird) is free-as-in-beer, but people are perfectly accepting of $10 - $40 charges in the Apple or Microsoft space. You get the sense that some people would be horrified if a Thunderbird addon carried a charge.
But what that means is that the Thunderbird addons are virtually impossible to make sustainable as businesses. So MEALS (Mozzilians Earning A Living Somehow) resort to forks, and we lose the benefit of their future efforts. In the fork, they can try to absorb the revenue streams that Mozilla relies on, or reset the cultural environment to be more in alignment with a commercial model.
What a pity. If we could figure out a way to all work together, then the net effect would be so much more powerful. If there was money to be made, we’d have a much more powerful product to present - and the total pie to share would be so much bigger. Yet I fear that the cultural pollution has already occurred, and any attempt to change the mindset will just fail.
KNIFE anyone? (Kent Nicely Introduces Free Extensions, thereby stabbing himself and the rest of you in the back. But please try my extensions!)
rkent
P. S. As an attempt to put my money where my mouth is, I paid $1.50 at istockphoto for the image above. The process took me at least an hour to figure out, after reading all of the legal language I feel like I must be a criminal, and I’m still not sure that I didn’t do something wrong that won’t cost me my entire retirement savings in liability. There has got to be a friendlier way to get micropayments!
Thunderbird 2.0.0.21 was recently released by the Mozilla Release Engineering team. The difference this time, well, all content, including the /start/ page is now hosted on mozillamessaging.com. Makes quite a large difference in our bandwitdh consumption, don't you think ?
The only problems I've been dealing with because of this is simply the amount of logs generated by this increase in traffic. Everything is fine now, but for a little while there, the rapid growth in traffic caught me a little off-guard. I was expecting more traffic, yes, but not quite that much more. It's actually a good thing, really, because except for a little disk space annoyance, the infrastructure behind mozillamessaging.com has handled a 20x increase in traffic without breaking a sweat. Good!
Today, the SeaMonkey project released a new version of its all-in-one internet suite. SeaMonkey 1.1.15 closes several security vulnerabilities and fixes several smaller problems found in previous versions.
The way we maintain the bug database for Thunderbird is mainly through volunteer work. People that care enough to report bugs, people that care enough to read bugs and people that care enough to follow bugs. Helping the classification of bugs - finding duplicate bugs and making sure that all the information provided is there.
Some people who would like to join can't because :
They think there constributions are not worth it
Think they are going to make mistakes
Don't have buzilla rights
Think that their english is too bad
And that's why we organize events so people that are not too comfortable or that want help can find other users that have more experience and that are willing to help new users. We call these events bug days.
We use a wiki page to announce what the focus of the day is. We also use quality.mozilla.org to announce the events and make them available in ics format.
Our next event is this Thursday. Feel Free to Join.
One of the interesting applications of automatic categorization of message items is the categorization of feed postings. Feed aggregations like Planet Mozilla often have many more posts than is convenient for most people to keep up with. How do you decide what to read, and what to skip?
The bayesian classifier that is part of the Thunderbird and Seamonkey distributions has been generalized by me over the last few months to allow it to be used for such categorizations, rather than be limited to spam recognition as originally implemented. I can demonstrate its use with my TaQuilla extension, which allows automatic tagging of message items using the bayesian classifier. The release available on AMO works with Thunderbird 3 beta 2, but only supports email messages, not RSS feeds. I am extending the mailnews backend in bug 471833 to also apply bayesian filters to RSS messages. My private patch now does that, so I thought I would demonstrate how it works.
I’ll use my Planet Mozilla feed items from Thunderbird, and apply the tag “Interesting” to posts I want to read. First, I need to do a little training to show the bayes classifier what is Interesting and Not Interesting. So I picked posts from two people and flagged them as Interesting, and two others as Not Interesting. (Note this is a demonstration only, no disrespect is meant to the poor saps whose posts I’m calling Not Interesting here!) For Interesting, I chose posts from Mitchell Baker, and the Rumbling Edge posts from Gary Kwong. For Not Interesting, I chose the Mozilla Community meeting note posts from bsmedberg, and the European Community marketing efforts posts from William Quiviger. I picked two from each author to train, for a total of eight trained posts. After training, I reran the bayes filter on the folder to see how effective it was in categorizing posts similar to those that I had trained.
So, how did we do with this minimal amount of training?
The bayes filter determines a score of 0 - 100 for each post, with 100 for posts that most closely match the category, and 0 for those that most poorly match.
For the Rumbling Edge posts, I had 7 total in my sample, and used 2 for training. For the remaining 5 untrained posts, 4 had a score of 100 showing a strong match, while 1 had a score of 84. Looking at that post, it was quite different from the others, which were mostly lists of fixed bugs.
For the Mitchell Baker posts, of the 5 untrained posts, 4 had scores of 90 -100, and one had a score of 49, which is indeterminate. So close, but not perfect.
The quality of the match was similar for the “Not Interesting” posts, though of course here our goal is a score of 0 instead of a score of 100. For William Quiviger’s posts, the 7 untrained posts had scores of 0 or 1. For bsmedberg’s Meeting Notes posts, all but 1 of 19 untrained posts had scores of 0, and one had a score of 9.
So overall, this is pretty good categorization with minimal training. In the future, all new posts that arrive will be automatically categorized, with posts having a score of >50 tagged as Interesting, and < 50 untagged. If I am unhappy with the tagging, I can train additional messages by simply applying or removing the tag from the incorrectly categorized post (which is a single keystroke in Thunderbird.) To display posts that I want to read, I can setup a saved search folder that shows only Unread Interesting posts, and sort that by the percent match.
When I do this, and apply it to all 578 posts that I currently have in my Planet Mozilla folder, here’s what I get for the top 17 posts:
So I see all but 1 of the Rumbling Edge posts, and all but 1 of the Mitchell Baker posts.
What about the other Interesting posts? The Burning Edge and Seamonkey posts are very similar in intent to the Rumbling Edge posts, so it is understandable that they are also rated as interesting. Daniel Glazman’s post mentions “messages”, “Thunderbird”, and “mail” so it is also understandable. The Aza Raskin hit seems more random, the matched tokens are common words like “how” and “they” which would get averaged away with more training.
So overall, I think this will be a useful tool to add to Thunderbird to assist users with sorting of massive planet-style feed aggregations. I expect that the features demonstrated here will be available beginning with Thunderbird 3 beta 3 (in late April) when the TaQuilla extension is loaded.
Andrew Sutherland pointed me at a patch that speeds up gloda operations in debug builds by a shocking amount - https://bugzilla.mozilla.org/show_bug.cgi?id=456272. It turns off some debug-only autolock code in xpcom. I’m sure the debug code is very useful when you’re debugging multi-thread locking code, but the speedup without it is intoxicating. All the usual disclaimers apply, but if your debug build is painfully slow, the patch is out there