The roads I take...

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 32/2009 (August 3 - 9, 2009):

• Build and Release Machinery:
  When I got alerted to the link to the source tarball for 2.0b1 being wrong, I tracked the issue down to a wrong filename caused by a variable in the build harness, which I could then fix easily for all our future releases.
  While I was there, I decided to finally go the last step for release automation and file a patch for moving the CC* releases factories to buildbotcustom. When testing this patch with current buildbotcustom, I saw some redness caused by an earlier patch and fixed it by using correct references to the mozilla directories.
  I also helped Thunderbird folks to fix some bustage of their L10n builds when they switched to the same repack classes we are using (and which share code with Firefox et al).
  The compile failures of comm-central-trunk builds on two Linux VMs were solved by increasing their RAM, at the same time the disk size of one of them was increased to match our other boxes. Thanks to Mozilla IT for those upgrades.
  The bad news from IT come mainly in the form that we don't think that the network issues with Parallels will be fixed, so we need to find other solutions to get the two VMs we are still missing. All in all, the Parallels experiment ended up as quite a disappointment. Even if it sounded good to have virtualized Macs, there seems not to be a mature solution to do that in a server-style environment yet.
  Continued investigating the issue with the "hoshi" box that does SeaMonkey 1.1. Linux builds, might all come down a filesystem problem I can't solve remotely.
• Build System:
  Porting changes from the Mozilla build system to the comm-central release system is an ongoing and probably never-ending task. While Serge has gone for porting a number of patches in that area, my watching of the change feeds of the relevant files ended up badly as I couldn't find the time to flag new changes as needed or unneeded and much less do the actual porting.
  For some time, I had the thought in my head to do a webtool that would poll those feeds and enable marking of changes we don't need to port or are ported, as well as bugs filed on porting, etc.
  I finally got around to working on that tool this week, and while it's mostly working, I'm a bit reluctant to link it publicly, as the main page still lists almost 350 changes to be looked at right now, and a good number of that still need to be set to being ignored (i.e. not needed porting) or being already ported. Also, right now only I can edit anything in the tool, but better permission management can be added easily, it just wasn't a priority.
  If you are interested in that tool, pass me a note, I can give you a link - it's publicly accessible, just not openly linked for now.
• Download Manager:
  Once again, I came back to download manager work this week. Linking progress windows from download manager as a "Properties" view was something I left out in the original patches so development of the two parts could progress individually. Now that both exist, we can easily link them. I have a patch up that would have review, but I need to look into one nit/improvement before actually landing it.
  And while I was at it, I went through all open bugs in the "Download & File Handling" component of SeaMonkey and triaged them - some were moved on the respective backends in toolkit or core, the majority could be duped or otherwise closed based on the rewrite and the testing I did on all that rewritten UI. In the end, slightly over 30 open bugs were left in the component out of 120 or so before my triage. It's nice to be able to find the really relevant ones easily now.
• German L10n:
  Once again mainly mailnews updates to keep SeaMonkey L10n up to date.
• Various Discussions:
  1.8.1.23 security release - build and planning issues, tabmail, new Mac theme, code style discussion, www.mozilla.org planning, Mozilla Camp Europe, etc.

Porting things is a major topic in SeaMonkey these days, esp. in the ongoing effort to go from a left-behind codebase we inherited in 2005 to a product that is up-to-date with all the things ongoing in Firefox 3.5, Thunderbird 3 and even beyond. We made a good number of large steps already, but more is to do. Many of those things are opportunities for new contributors to learn Mozilla code, if you're playing with the thought of helping out with code, don't be afraid to look into the TB2SM and FF2SM bugs that list application-specific thing we want to port from Thunderbird or Firefox. Of course, we need to and will add our own innovations next to and/or on top of those things, after all, we are more than a sum of Firefox and Thunderbird (download manager is a good example where we don our own thing on top of their base).

That said, our focus in about the last two months of SeaMonkey 2 development, which we are probably entering right now, must turn more and more to fixes. Some glitches can be fixed more easily, some are harder, and we need all the help we can get to smoothen things as much as possible for 2.0. Still, I don't expect SeaMonkey 2.0 to be perfect. It surely will be better than 1.1.x in the vast majority of things, but in some, it might be worse. We're trying to fix everything we can - but after all, we're a rather small group of people, working on this project in their free time. And we are humans, which in our very nature makes us not perfect, and neither the products we create. We're damn good people though, and we're trying to do our best, and we hope that will make SeaMonkey 2.0 a damn good product as well.

Oh, and do you know the new "suite." T-shirt on the Mozilla Community Store?