Shredder Icon and artwork needed!

If you ever used a Firefox alpha or a nightly build, you know it’s called Minefield. As I’ve explained, we’re going to do the same for Thunderbird, using the name “Shredder”. Now we need some artwork!

First order of business when I grew up would be the t-shirt design, but in this day an age figuring out the icon set is the more environmental approach. Submissions should be sent to me, or ideally, attached to this bug.

For background, see the minefield icon, and the current Thunderbird Debug ICNS file, which while pretty, has nothing to do with sharp blades whirring.

Thunderbird and SSL certificates

Thunderbird was recently released to the world: yet another security release for Thunderbird. Yay, and thanks to all involved! All was well, until news came in through a bug report that one of those included updates is problematic for some users.

Specifically, as part of making Firefox, we made a change in how the underlying platform handles SSL certificates. That change was made to increase the privacy of people visiting certain web pages, as documented in this advisory.

The problem is that the switch (asking users to confirm that they want to identify themselves with a certificate) makes sense for web pages, but it doesn’t make sense as implemented for email transactions. There’s a lot more detail in the relevant bug.

Luckily, this problem likely doesn’t affect the vast majority of Thunderbird users. It only affects users who are issued a certificate to secure the communication with the mail server, rather than relying on passwords. With the release, those users end up being asked to confirm the use of the certificate on every connection, which gets to be annoying.

Most of the users affected are likely in large organizations, as they are the ones who tend to issue their own certificates. Luckily, those organizations also often do their own QA before a deployment, so in all likelihood few people will be exposed to the bug.

Getting a fixed Thunderbird out is planned, but we’re trying to figure out how to prioritize this release relative to the other releases.

In the meantime, there is a simple workaround that can be applied per user (revert a preference setting), or, for those deployments using autoconfig, by tweaking the central configuration file.

We could also release a XPI add-on to fix the preference, but that may or many not be easier — feedback welcome.

I’d love to hear from administrators of large Thunderbird installations in particular, as this bug highlighted for me several of the challenges we have in making sure that our processes are aligned with those of large deployments.

I’m also thinking that we need to setup better communication channels with people deploying large installations of Thunderbird (email lists, different blogs, etc.). If you’re involved in large-scale deployments of Thunderbird, email me and let me know your thoughts.

inames: any hope?

So I have this nice short iname that I registered last year when I was poking around OpenID and the like. That registration is about to expire, and I think I have yet to use it except for testing purposes, in part because there’s no way when being asked for an OpenID to know whether the server supports inames or not. In addition to being just shorter hence cooler, I can’t even remember the benefits of inames over traditional URLs. I guess I’ll let it lapse…

Somebody fix identity. Please?

Contagious user interface concepts

Every now and then, a UI concept is so good that it becomes contagious in fascinating and frustrating ways. I’ve run across two recently.

The first is the iPhone touch screen. A few months ago, when I first got my iPhone, after playing with it for about 30 minutes, I went back to work on my mac, and my fingers automatically expected things like the two-finger zoom to work. I was stunned. Not surprisingly, that is now a feature of the new Macbook Air, and I expect it’ll be in all mac laptops.

The second occurred to me this morning. I was using ssh (a command line tool) to log in to a variety of machines with cryptic addresses, and I knew that I had to start looking for a place to write down those username/hostname combinations. At the same time, I realized that what I really wanted was the awesomebar for my terminal window. The notion that “the computer” should just remember what you’ve done no matter where, because past behavior is the best predictor of future behavior, and that we can implement that quite well with simple mechanisms like keeping a history and doing some math on that history, is a contagious idea. (Note to unix weenies: I know that with the right magic i can get some pseudo-awesomebar within bash. Not good enough! I want bookmarks, tags, weave!)

Naturally, it applies to Thunderbird as well. I routinely go back to “the same” emails. We should find a way to make that as obvious and invisible as Firefox 3 does for web pages.

Vancouver Credit card recommendations?

I’m looking to change my VISA card, as the current one gives us points towards ‘stuff’, most of which I don’t need. I’d be more interested in cards that either served some sort of purpose (e.g. the VanCity cards) or points that are more useful, such as high-leverage travel frequent flyer miles on either flights to the US or to Europe.

Any recommendations?

Naming alphas

Software production is a lot like sausage factories. The end result is nice, but peeking behind the factory walls isn’t always pretty (cue scene from Tintin in America).

It’s been educational to go through the process of picking nominations for the next alpha release, understanding the interactions between Gecko changes and the impact on Thunderbird, and more. We’re getting there, though, as soon as we can figure out a couple of last issue. But then there’s the issue of “public perception”, in particular what we should call this next release. Because names are loaded, and version numbers even more so.

So what is the point of doing this next release? There are lots of somewhat conflicting goals:

  • Because it’s time: it’s been a long time since there was any non-security release of Thunderbird, and that’s always dangerous. Software that’s not used by people outside the inner circle tends to have hidden flaws that get harder to fix with time. So it’s important to release something, anything.
  • Because we’re on trunk: Thunderbird development has been going on on the “trunk” of Mozilla for several months now, and as a result a lot of changes motivated by both the evolution of the platform and Firefox 3 have impacted Thunderbird. It’s good to get feedback on the consequences of those changes, whether that’s cool new features like the Add-on manager or core changes like the changes in the widgetry on the mac.
  • Because it’s a new team. The Thunderbird 2.0.0.x releases you’ve seen over the last few months have all been done by the Mozilla Corporation engineers who have those processes ironed out. Some of us on the Mozilla Messaging side are new to making Mozilla releases, and it’s certainly better for everyone if we work out the kinks in releases doing early releases rather than “important” releases. At the same time, having a new team means that we can challenge some of the old ways, and consider doing things differently because the environment is different.
  • Because we want to release often: Both Dan Mosedale and I really want us to move to a more agile development model, where releases aren’t that hard, and where we can experiment with changes without huge impact on the QA process. That’s going to be hard, and involve investments in all parts of the pipeline, from build automation (Rick’s on that), to unit test coverage (Mark’s on that), to rethinking how we do QA (Gary and Wayne are on that). But getting there also means understanding, documenting, and streamlining the release process.
  • To re-engage with the add-on developer community: there’s lots of work to do to make sure that when 3.0 is ready, the add-on community has been part of that process, so that their extensions can be ported to the new codebase. Having a release that they can target that is based on trunk is a good first step there (finishing and documenting STEEL is another big step in that direction).

Note that there’s a big reason to release which isn’t mentioned above, and that’s “to get feedback on the big changes in the next major release of the product”. And that’s because none of the big changes that we’re hoping to have in Thunderbird 3 are in this build. So for most users, I expect that the differences between this next release and Thunderbird are going to feel pretty minor. Which is how it should be at this stage.

However, given how long it’s been since there’s been a feature release, it’s likely that if we label this release “Thunderbird 3.0a1”, that we’ll both get complaints about how little has changed since Thunderbird 2, as well as give the impression that we’re close to nailing down Thunderbird 3, neither of which are true.

Furthermore, we really do mean that it’s an alpha release. There are no guarantees, there will be minimal testing, and it’s possible it will eat up all your mail (although unlikely =). So calling it Thunderbird anything is likely to confuse people who don’t follow Mozilla closely.

Given all that, I’m thinking that this next release should be called Shredder a1, with Shredder (Rick Tessner’s brainstorm) being to Thunderbird what Minefield is to Firefox. We probably won’t have the word Shredder in the product for a1, but hopefully for a2.


Thunderbird team needs help from Python/Perl build engineer

If you’re a Thunderbird fan but not interested in fixing some of the nasty C++ problems we tackle in the product, you could still be very, very helpful if you can help us with a little Python/Perl build problems.

Specifically, Mozilla has a great system called “try servers” where one can submit patches against the tree, and the build system runs builds on Linux, Mac and Windows, using those patches, then serves those builds for testing. This is really helpful to figure out if proposed patches solve specific problems, especially when the developers aren’t able to reproduce the bugs, but testers can. It works great for Firefox development right now.

The only problem is that there’s a little bit of patching needed to the try server code itself to make it able to work with other targets besides Firefox, as described in bug 431375. Ben Hearsum, a build guy from Mozilla, is happy to help someone figure out those patches, but he doesn’t have time to make it happen right now.

From what i can tell, required skills include comfort with CVS and Linux, Python, Perl, and some build engineering common sense.

Thanks in advance!