The roads I take...

I took some time off on Sunday and Monday's time just ran through my fingers, so once again this status report runs late, even later than in some other cases...
Still, here's a summary of SeaMonkey/Mozilla-related work I did in week 30/2007 (July 23 - 29):

• Releases:
  I uploaded a few more builds for SeaMonkey 1.1.3 this week, and spent some time assessing if/when we might need a relatively fast 1.1.4 release for some important fixes that also make Firefox do a quick 2.0.0.6 - and closing the security hole that could possibly be exploited when sending mail with SeaMonkey set as the default mail client using a browser like IE6. It's apparently not that easy to trigger, but still well worth fixing. Oh, and the best workaround to not be vulnerable is to only use the SeaMonkey browser when you have SeaMonkey set as the default mail client on Windows
• Breakpad activation
  Apparently, when we integrated the Breakpad crash report tool recently, we missed a tiny variable definition so that it didn't get actually enabled. I spotted Thunderbird folks fixing the same problem and did the same for SeaMonkey. Seeing reports coming in shortly after that convinced me that we really have this working now
• Build and tinderbox issues:
  When our friend Ted ("luser") tried to help us and fix an interesting issue with filepicker theming, he broke Windows builds completely, I checked in the fix he pointed me to. When then had to deal with startup crashes he also helped me fix. When having a few crashes on one of our tinderboxes, I grew tired of logging in and clicking away the dialog fast, so I finally disabled sending crash reports from those boxes. And while I was looking into configurations, I also cleaned up their mozconfig files, leaving out all unneeded/default options.
  As the startup crasher mentioned above involved files missing from Windows packaging, I also did some work to make a simple script run on my private tpol tinderbox (listed on SeaMonkey-Ports) that diffs file lists of dist/bin (pre-packaging) and dist/seamonkey (for-packaging), which makes it easier to find such unpackaged files and add them to the packages file as needed.
• Wallet to satchel conversion:
  After Neil finished up his great work on making xpfe autocomplete compatible with toolkit far enough, we now could actually do the swich from wallet to satchel for auto-filling of web forms. In current trunk builds, you'll notice a nice dropdown with previously entered options in any textboxes of webforms you fill as a result of this recent change.
  And there's more to come - the next target is to get the new login manager to take over password management so we can throw out the old and unmaintained wallet code completely.
• MoFo ED Search Committee:
  We had our first phone conference, talking about how this process of interviewing will work, I think some notes about should be posted soon. We want to keep this as transparent to the community as possible, though there will be a first phase where we can't tell candidates or where they are coming from in the public, of course. Before a decision can be made, we plan to have an open round where the community can participate in the interviews, but first the candidates and ourselves must feel comfortable enough that they can step in front of this wide community and reveal their personalities.
• Source L10n:
  When looking into packaging as pointed out above, I ran into mailViews.dat not being localizable from CVS for default profiles (not even on Thunderbird), and filed that.
  The move away from wallet, also pointed out above, will resolve one of the still open areas of source L10n. We're not there, but we're coming closer and closer.
  One point I'll need to investigate now is how/if we can set up mechanisms/machines that build langpacks and do repackaging of builds so we get localized nightlies.
  Following that, I'll also need to look into what to do with releases, but that's probably an even more complicated topic.
• German L10n:
  Reviews for my big sync patches are coming in and I integrated some of those comments locally already, but I'm a bit overwhelmed with work atm, I might need some time to work through the rest of those huge comment lists.
• (Undisclosed Project):
  The groundwork for SeaMonkey-related business project should now be finished for the most part, I hope I can announce it in the next few days.
• Various Discussions:
  Thunderbird future, FF3 URLbar experiments, automatic update system, accessibility slowdown, Vista compatibility, trunk freezes and milestones, FF3 download manager UI, etc.

I'm currently a bit swamped with work but I also realized I need to spend at least some of my time on things that are not related with this work, maybe even try to not always avoid the harsh glow of the daystar, accepting it to do some bike tours around Vienna or such. Maybe such activities can even increase my work efficiency - we'll see about that

There has been some rumbling today about the future of Thunderbird, starting with Mitchell's call to action. Thunderbird has been a step-child of the Mozilla Corporation for quite some time while it spearheaded the rediscovery of the open web by spreading Firefox. This is an important job, but a company of perhaps 150 people or so working on Firefox and two working on Thunderbird just doesn't work out. I guess that time has come when MoCo has to split off the step-child mail client and become the Firefox Corporation that it has been acting as for a while now. In some way, mail client and browser get separated once again, some years after doing that on the technical application level.

This is a possibility for Thunderbird to step out of the shadow of its overwhelming browser brother if it's done right. Almost everyone, including Scott as the head of Thunderbird development, is thinking the best option is to form Thunderbird into a community project like SeaMonkey, and Sunbird (or even Camino-like-Firefox).
I also think that a Thunderbird community project is a good solution for stepping out of Firefox' shadow, but I hope the organizational overhead can be kept as low as possible. We don't have any official organization for SeaMonkey, being backed "only" by the Mozilla Foundation, and that structure works well (the SeaMonkey development community might be bigger than Thunderbird's at the moment, despite probably the opposite is true for user numbers). Of course, Scott and David should still be paid for Thunderbird development, so there has to be some form of organization. Maybe we should even think about an organization that backs multiple Mozilla-based projects, or this can even be done via the Foundation itself? Let's see how this turns out.

In any case, the SeaMonkey project will happily team up with the Thunderbird project where useful, it's in the interest of both our projects to have a healthy and well-developed email and newsgroup backend, so we both can deliver top-quality software to our respective target audiences.
I wish the Thunderbird good luck on this interesting journey and hope that we can continue working well together for a good future of Mozilla-based Mail and News clients.

Another week fully loaded with work is behind us, even though I managed to take a full day off this weekend Here's a summary of SeaMonkey/Mozilla-related work I did in week 29/2007 (July 16 - 22):

• Releases:
  Firefox 2.0.0.5 has been released even two days before it had been pre-scheduled. This increased the pressure on us to release SeaMonkey 1.1.3 pretty fast. It also let them slip in a mac scrolling bug that doesn't look good, due to us releasing 2 days later we could sneak in the fix for this.
  A Firefox 2.0.0.6 may follow fast with another security fix and this mac scrolling patch, depending on how grave the security fix sounds for SeaMonkey users, we might skip this one and sync SeaMonkey 1.1.4 with a Firefox 2.0.0.7 which should follow in roughly 6 weeks in a normal schedule.
  With SeaMonkey 1.1.3, we could demonstrate how healthy our community is, as we could spin and QA builds (on all 3 major platforms) for this release within only a few days. Thanks to everyone who did help with that!
• Cleanup of Old xpfe Code:
  I did remove xpinstall/wizard from cvs this week, finishing that parts I intended to kill of the xpinstall/ directory. Interestingly, some code from there was still built, even in Firefox, though it hadn't been in use for a while. Because of that, I could even reduce codesize with that removal of old code.
  Some major work has been completed, I'll look into what can be done in other directories sson.
• Tinderbox work:
  The sea-win32-tbox Nightly build tinderbox should be fixed now. I logged in myself and couldn't see the problems that coop encountered when logging in himself. I then found that we just didn't pick up the startup test HTML being a .lnk file and copied that actual HTML there, which worked.
  Thanks for community access to those tinderboxen, it seems to have not only caused, but also solved this problem
  I also watched the phlox box on SeaMonkey-Ports closely, and realized I needed to increase the timeout a lot so that the Tdhtml test would run again. Apparently it regressed a lot and I filed a bug on this.
  Also on phlox, which also acts as nightly and build machine for the 1.8 branch, I could track down the regression range and the probable fault of SeaMonkey 1.1.3 showing chrome errors when launched directly for the disk image - not sure if we will ever be able to fix this on the branch though.
• Source L10n:
  I checked in the patch for langpacks and L10n repackaging, now we need to get boxes that use this code - and then we should get near to supporting source L10n, only a few code parts don't support it yet.
• German L10n:
  I could check in the netwerk patch and did another checkin to suite L10n following the outcome of the discussions about common strategies for German L10n.
• (Undisclosed Project):
  I again spent some time on a SeaMonkey-related business activity that should be disclosed soon.
• MoFo ED Search Commitee:
  Now it's official: As Mitchell points out in her blog, I'm one of 6 people in the Mozilla Foundation Executive Director Search Committee. I hope that this team can help to find someone who can work for the as much of this large community as possible. It won't be an easy job to find such a person, and it won't happen somewhere in the dark. From what I hear (and I support this), we'll try to do many steps of this process in the open, accessible to the whole community, though not everything can be done in this manner. I think the 6 of us are a good representation of interests in this community and we'll do our work to serve this as good as possible.
• Various Discussions:
  Some more touches on the Bugzilla reorganization,Firefox 3 location bar, moving from wallet to satchel/pwdmgr, prefwindow work, Lightning integration, etc.

As I got so good results with openSUSE FACTORY on my laptop, I also upgraded my main machine to it, and it almost feels more stable than openSUSE 10.2, even though it still is in an Alpha mode. Probably some of the newly found stability comes from opening my computer case though, as in a closed state the video card was too poorly cooled (it uses passive cooling by utilizing the air flow from the CPU fan), which was the reason for a few graphics hangs lately when we had that tropical air blown up from Africa right here to Central Europe.
The 2.6.22 kernel provides me with CPU core temperatures from the coretemp module, which I like anyways, and the rest of the system feels much more mature than expected and works really well. I'm sure openSUSE 10.3 will be a great distro to work on and I'm looking forward to also using it on my servers when it goes final

The Firefox team has released their 2.0.0.5 security update well before schedule because of the firefoxurl: vulnerability that got much press attention, even though (or because) it is only partly the fault of Firefox's commandline handler, which they introduced for better Vista compatibility.

While SeaMonkey did not pick up that better Vista compatibility and has its rough edges on the new Microsoft OS because of that, our internet suite is also not vulnerable to that security issue. Still, Firefox 2.0.0.5 and its Gecko 1.8.1.5 core also features other security and stability fixes, and we also have a few small SeaMonkey-specific patches to ship.

All those get fixed with the SeaMonkey 1.1.3 release we published today. Trying to stay in sync with Gecko and Firefox made us go faster with this as we wanted, but we got some QA on all platforms due to our great community, and we could even include a late Mac fix that didn't make Firefox but decreased user experience somewhat on OS X.

While going at higher than usual speed for that release, I was listening to a few new CDs I've purchased this weekend from Amazon, one of which is by chance called "5th Gear" (by Brad Paisley), which fits really nicely with this work

I hope you can slow down a bit at times, even though this hot (yes, tropical heat is here in Vienna at the moment) new software is quite speedy
I hope we could fix some mistakes (#6 on "5th Gear"), so that you can find no software better than this (#11) for being online (#3)!

Here's the summary of SeaMonkey work I did in week 28/2007 (July 9 - 15):

• Releases:
  Firefox 2.0.0.5 has been moved forward to happening the upcoming week already (!) because of the firefoxurl: vulnerability - at least if no further patches to include in this release come up.
  For us, this means, we will need to go fast if we want to release SeaMonkey 1.1.3 in sync with this release.
  (By the way, SeaMonkey 1.x seems to not be vulnerable to this mentioned security problem, as the affected code was only introduced with Firefox' Vista support, and we never adopted that. So we don't have good Vista support, but one security problem less.)
• Cleanup of Old xpfe Code:
  I managed to remove xpinstall/packager from cvs - at least everything but 3 files that are still used from elsewhere. I even could remove a few unused files from toolkit/mozapps/installer/ in the process.
  Whoever hasn't realized it yet, creating tar/zip packages for any apps can be done via "make package" from the (objdir) toplevel directory nowadays. Be sure not to try a make in xpinstall/packager any more, there's no makefile left there.
  The next target in this area is removing xpinstall/wizard as well.
• Breakpad:
  As reported earlier on this blog, I could move SeaMonkey to the new, open source "Breakpad" crash reporter tool now. The old, proprietary Talkback tool is not needed any more on trunk.
• sea-win32-tbox Failure:
  While working on getting me access to the SeaMonkey tinderboxen (all community projects get control of their MoCo-hosted tinderboxen), Chris Cooper from the MoCo build team encountered a very strange failure of our SeaMonkey Windows machine. I've been working with him as much as I could to find a solution, but we failed so far. We hope we can get this fixed very soon.
• Source L10n:
  As a further step to SeaMonkey "source L10n", I could check in a patch to move searchplugins to locales. After some discussion on that topic, I decided that we will only support PNG icon images for searchplugins added by localizers - so localizers should convert any GIF icons they might have for plugins in their language to PNG. The backend continues to support all of GIF, PNG and JP(E)G files, so Add-On searchplugins are NOT affected, this is only for those added by localizers in CVS.
  We don't support Firefox' OpenSearch XML format yet, we still stick with sherlock plugins, but we use the same style of list.txt and fallback as Firefox L10n for selecting which plugins to include, so localizers don't need to add 1:1 copies of any plugins we already have in en-US, they just need to add/leave their name in list.txt to have them included.
  I also did a new patch for langpacks and L10n repackaging, which should take us the next step towards the goal of CVS-based L10n for SeaMonkey.
• German L10n:
  I resolved a few long-time open bugs on SeaMonkey L10n, and I made German toolkit/ L10n complete again. We're also currently in the process of finishing up a discussion about translation of "want"/"would", so I hope we should come to a conclusion and new versions of my sync patches soon.
  Repeatedly, such discussions bring up cases where the original wordings could be improved, the most recent one is about superfluous HTTP Auth. I'd hope that localizers of other language also do bring such issues that arise while localizing back to the original en-US by filing bugs. This way, we can improve the UI for everyone.
• Crashes:
  No, I didn't fix crashes unfortunately. But since I'm using trunk now for everyday work, I'm actually encountering a few, and using a debug build for all that work, I'm able to file some stack traces.
  I just hope those developers who know more of the C++ code can also find fixes for those.
• UA Spoofing:
  I filed a bug on my proposal of a dynamic UA spoofing solution and wrote a rough spec for it. I really hope we get someone to work on this.
• (Undisclosed Project):
  I spent quite some time of a project I'm planning to do as a business which is SeaMonkey-related, but I can't disclose it yet to the public, as some formalities are not yet finished. Be sure to hear some great news soon.
• MoFo ED Search Commitee:
  I had a phone call about the search commitee for a new Mozilla Foundation executive director, which I'm taking part in. I hope I can serve the whole Mozilla community with helping to get someone in this position who really fits us well, and who understands and can support as much of this large community as possible.
• Small Things:
  Hopefully the -moz-image-region reftest I have been talking about a few weeks ago can be added soon, as I now know where to add it, did a patch and requested review.
  If you might actually read blog entries of mine on home.kairo.at with a recent trunk build, you might have noticed a horizontal scrollbar appearing uselessly. I tracked this down to a layout regression and filed it with along with a simplified testcase.
  I also filed bugs on an interesting table rendering bug I encountered and the POP3 new-message check failure, both happening on trunk.
  And I wrote up my XULRunner wishlist, which includes items from the SeaMonkey and L210n areas.
• Various Discussions:
  Finishing touches on the Bugzilla reorganization,Firefox 3 location bar, moving from wallet to satchel/pwdmgr, printUtils work, newsgroup reordering, etc.

After recovering my recently broken laptop system, I dared to upgrade it to the openSUSE FACTORY distribution, which is the openSUSE for what we call "the trunk", i.e. the bleeding edge development version for the next release, which is openSUSE 10.3 in their case. They are near to 10.3 Alpha 6 right now (alpha6 doesn't feel too unfamiliar for this point in time), but from the short looks I got, this doesn't feel like an Alpha distribution at all, it's pretty decent actually. It looks like openSUSE 10.3 will be a great product, and worth upgrading also my servers to (which I had planned anyways).

As AllPeers, Mark Finkle and Songbird have all posted their wishlists for XULRunner's future, I think it's a good idea to throw mine in, in the light of possible Mozpad acitivities on such items.
Not that this is my personal view as a SeaMonkey and L10n contributor and no common view of the SeaMonkey project or the Mozilla L10n Project (MLP), though I'd guess that some of those items would be on the wishlists of multiple community members in those projects.

• Killing app-specific differences in toolkit:
  Toolkit and other core code still contains app-specific ifdefs in many cases, which block moving the applications to XULRunner. There should be no need for MOZ_PHOENIX, MOZ_THUNDERBIRD, MOZ_SUITE and friends in that code. We came across such problems in printUtils recently, and I'm sure there are still enough others. Efforts like generalizing openURL() are good steps, but actually long overdue.
• More robustness in mozStorage:
  When the topic of moving any code to mozStorage from RDF or Mork backends in SeaMonkey or MailNews comes up, people keep telling me there are so many warnings around how easily things can go wrong with mozStorage/SQLite when it comes to other apps wanting to access our data or even multiple threads accessing the database (see How to corrupt your database). If we want to make mozStorage the general backend for databases in XULRunner, we need to find way so that that developers don't back out because of such fears before even trying to use it.
• Template Query Processor for mozStorage (bug 321172):
  SeaMonkey has a lot of UI that is based on RDF templates. If we should be moving to mozStorage as a backend for much of our data, it would be very helpful to be able to be able to build UI as easily as for RDF, which needs templates to work with mozStorage.
• Pipe-based IPC (bug 68702):
  Invoking external processes and controlling them via stdin/stdout or even named pipes is something that many more XULRunner apps will want in the future. I mostly care for having a good way to integrate EnigMail/OpenPGP into SeaMonkey by default, which needs to call gpg through such a mechanism, but I'm sure there are many other needs for this.
• OpenSync support (bug 303963):
  While the linked bug report is about MailNews and most of the work for this is probably app-specific, it might be a good idea to provide hooks on the platform side to hook into this open, cross-platform data synchronization framework, so it's easy for Mozilla/XULRunner-based apps to use it and provide synchronization with a wide variety of devices and applications.
• Profile management improvements:
  Profile roaming seems to be something that gets requested again and again, but does not work well. The mostly working framework we have for that in SeaMonkey 1.x is broken with toolkit profiles on trunk (bug 378647) and there's no code for doing this with toolkit profiles. I also would love to have profile language selection back if multiple languages are installed for the application (also an xpfe feature not supported by toolkit). Accessing one profile from multiple instances/processes (bug 135137) would probably be nice but is hard to get right.
• L20n (wiki page):
  The localization framework used for Mozilla applications up till now has its merits but also its share of problems. Based on what we know about current localization frameworks, which all have their own big problems, Axel Hecht, the L10n lead of MoCo, has figured out a next-generation L10n framework which he calls "L20n". We really need such an improved framework with one single file format for everything and enough flexibility for complicated languages (those are out there and currently not supported well in any software).
• Language switching in EM (bug 377881):
  Being able to easily install a language pack and switch to using it is good for L10n testers but sometimes also for normal users, esp. in multi-language families and countries. We should not clutter the interface for those users who don't need this, though. To achieve that, we can leave the current way of language handling in Extension Manager, just with small tweaks so that language switching is handled the same way as theme switching.
• Tray icon support (bug 325353):
  The main reason why the so-called "Quicklaunch" feature on Windows has remained popular with our users in the SeaMonkey 1.x product line is that they have a tray icon with a context menu that provides fast access to open browser and mail windows. Additionally, it kept mail libraries loaded and provided information about new mail arriving - and it allowed to close all SeaMonkey windows and still have fast access to the browser, mail and get this mail notification. It would really be nice if we could still provide that functionality with toolkit-based versions of SeaMonkey, but we'd need tray icon support in toolkit for that.
• Splash screen support (bug 329742):
  This might sound like a small thing, but having a splash screen gets branding across, which is why I believe many corporate users of XULRunner will want this, and on laptop machines with slow harddisks, even Firefox takes long to launch, with currently no visual feedback at all to the user that anything is happening.
• KDE integration (bug 140751):
  As a KDE user, like probably half or more of the Linux population, I'd really wish we could integrate more with KDE. We currently are able to fetch file type icons (moz-icon) from GNOME, and system settings also from there, but it doesn't help much when GNOME isn't configured much because I never use it. We've grown to use themes from KDE quite well in default themes, as KDE makes GTK inherit its settings and we inherit them from there, which works interestingly well. It might be worth to investigate how we can pick up other things through such channels, like e.g. default apps for certain MIME types.

I think I have touched my main wishes here, others might still come up to my mind later, but I hope they're only smaller wishes

For a long time, if you happened to encounter a crash on any Mozilla or Netscape release, the "Netscape Quality Feedback Agent" happened to pop up and you could send crash reports back to Mozilla. This agent was actually a license of the the proprietary "Fullcircle Talkback" product, which Netscape and later the Mozilla Foundation was allowed to use in a rebranded version, but only in their own products and without really changing the code.

Multiple problems came out of that, two being (in addition to the usual problems of products where you can't play with the source):

1. Any build not made by the Mozilla Foundation can not use this tool, including SeaMonkey releases that are built on my private machines.
2. The license prohibits anyone with access to the Talkback code to work on any similar tools, so most people who who wanted an open source tool as a replacement could not take part in developing one.

As our project got bigger, we finally found people who did want to work on this and didn't have Talkback source access, so they could start developing a replacement, and finally named this tool Breakpad (it's something like a pad to land safely on when the app breaks).

After Firefox has been using/testing the new framework for a while, SeaMonkey now has switched over Nightly builds from Talkback to Breakpad.
Starting with tomorrow, SeaMonkey nightlies should greet you with "Crash! Bang! Boom!" when it should crash, and you're able to send reports to the new servers Mozilla has for the new tool.
You can find the reported crashes and their info at http://crash-stats.mozilla.com/.

I just got word that a Status page for our Google Summer of Code project has been created.

As I mentioned earlier, we have a project in this program entitled "Make SeaMonkey Not Suck As A News Reader", and Markus Hossner is working on this under supervision from Karsten Düsterloh.
The new status page lists all tasks that either Markus has started working on, or which are in various review processes or even fixed already. Karsten will update the page through the project period so we can track what is going on there.
Oh, please don't edit this page yourself, we know you have wishes, but if a bug is filed on those in Bugzilla, you can be pretty sure Karsten and Markus will pick them up as time and the project scope permit. Karsten has multi-year experience in probably all areas the SeaMonkey newsreader sucks in, we can be pretty sure they'll cover quite a few hot spots. And it's really nice to see which ones Markus is currently attacking.

I just hope we'll soon find a few green spots on this list

But Yogurt, what is this place? What is it that you do here?
Merchandising!
(from: Spaceballs - The Movie)

I've just updated the SeaMonkey Merchandising Shop with designs that feature the ® instead of the ™ sign, as our trademark have been officially registered for a while now.
Following a popular request, I've changed the golf shirt to have the logo only at the front and an empty back - I also added the www.seamonkey-project.org URL to the front logo there though.

I hope to see many people out there spreading the word through this official SeaMonkey merchandise.



We offer "SeaMonkey - the T-shirt", "SeaMonkey - the mug", "SeaMonkey - the mousepad" and others; unfortunately we can't offer "SeaMonkey - the flame thrower" yet - the kids would love it

May the Schwartz be with you!

This week ended for me with spending lots of time helping on a local town festival and fixing up my laptop, but apart from that, here's a summary of SeaMonkey work I managed to do in week 26/2007 (June 25 - July 1):

• Next round of releases:
  The schedule for Firefox 2.0.0.5 has been posted, we'll try to once again snyc up with that and do a SeaMonkey 1.1.3 security and stability release at the same time.
• Bugzilla reorganization:
  Continuing discussion in m.d.planning about bmo structure, and it's still improving. Unfortunately we need to clutter the SeaMonkey product with a few components from old xpfe until branch is EOLed.
• places history:
  Checked in the patch for building toolkit mork history for non-places non-SeaMonkey apps only, which should ease our way to getting the backend switch implemented.
• debugQA:
  Mark put lots of work into making in-tree debug UI an extension so it's easier for us to switch it off for release builds. This will probably even allow testers who want it to use this extension on releases if they want. I hacked up a fix for our override to always use en-US for this as long as we don't support optional localization of such an in-tree extension.
  Additionally, I tried to get some solution for only displaying the build ID in the title bar when this extension is activated. I was pointed to Nightly Tester Tools (NTT), one features of which is to do exactly that for Firefox - and Mossop told me that NTT should install fine and work on toolkit-based SeaMonkey. When I wanted to test that, I ended up crashing in XPInstall code and debugging this with timeless, as I had hit this on my debug build. Due to this debugging session we did, he ended up knowing what the problem is (multithreading fun with JSContexts), and we can hope to see a patch soon.
• User Agent discussions:
  The whole UA discussion that Camino started with their decisions to add "like Firefox" to the string (already checked in), and which I contributed to with my blog rant and proposal/idea is still going strong: A proposal to not tell websites that Firefox is "Firefox" at all came up, as well as a proposal to make the SeaMonkey UA really suck. I'm opposed to both variants. User agents should be clear, informative and to the point (even our current one isn't really there), neither removing the actual name of the user agent from the string nor adding names of other user agents helps that.
  I have yet to see any better option than the proposal I made - but we also still need someone to work on coding up that solution that will help both users and evangelizers and could therefore help to make the whole web a better place.
• German L10n sync:
  Discussions are ongoing, I hope we'll get towards more consistency soon. I need to update at least one followup patch before it can get in.
• Breakpad:
  Now that the new breakpad crash reporter is basically working on all three major platforms, it would be nice to start testing/using it for SeaMonkey some time. Before that will happen (needs off infrastructure of that new code to be tested well enough), we want to add what SeaMonkey needs for it to work but in a disabled state. I had to update the patch I made for that this week as bug 383167 kept popping in and out the tree, making SeaMonkey switch back and forth between "traditional" nsSuiteApp.cpp and "modern" application.ini carrying that information.
  We're still waiting on an OK from Mozilla IT folks to use the mozilla.com socorro server for our crash reports though.
  Meanwhile, Talkback should be running again for Linux and Windows builds on trunk after some rework of the packaging on MoFo tinderbox machines.
• Various discussions:
  Firefox 3 UI: location bar, places/bookmarks/tagging, content handling (all of those could be interesting for SeaMonkey); HunSpell, application update service, and others

Items where nothing happened this week but which I hope to to get some traction on again:

• xpfe cleanup:
  Still need to look into that again soon, but it might be easier now that I don't care if Camino breaks (it's "like Firefox", it can't depend on any xpfe stuff, right? ).
• Killing wallet:
  Neil should be back, I hope to see patches from him soon that bring autocomplete up to a state where satchel starts working.

As a side note, I have been nominated for the Mozilla Foundation ED Search Committee, which will be working to find the next Executive Director for our official backing organization, the Mozilla Foundation. I feel honored by being nominated and hope to be able to serve the Mozilla community as a whole if I'll really can take part in that committee.

Disclaimer: Don't ever follow the steps below, or you will learn to avoid it the hard way (like I did this weekend)!

1. Copy your mom's photos to your computer and delete them from the camera.
2. Move (!) them from your Linux system to her USB stick and safely unmount it.
3. When she wants to copy them to her computer, discover that the USB stick is damaged and half of her precious photos are gone.
4. Suspend your system to disk and run reiserfsck --rebuild-tree on all your Linux partitions (one after another, until you realize the "home" one would have been the last one on the drive) in an attempt to find the deleted photos in the "lost+found" directory.
5. Reboot your system, only realizing once it's up that it resumed from the suspend you sent it to before, has a fair bit of file system data from the (old!) reiserfs tree in the cache and happily writes to the disk.
6. Kill that run of the system and realize you have to do lots of file system repairs again, followed by endless hours of restoring your system as you discover that common binaries (like udev, file, rpm and others) are no ELF files any more, and once you got a running rpm from the on-DVD live rescue system, discover that parts of your rpm database are gone as well.
7. Bang your head against the wall repeatedly and swear you will never try to get lost files this way again. Never. NEVER.

Thankfully this was just my laptop which has no important data (except the small bit of work I did on the train home on Thursday), my father found an app to undelete files on the camera's flash memory card (so my mom's happy to have the photos again), and I brought back the computer to a state where it works OK. Now I'm left with a reason to try out openSUSE 10.3 Alpha/Beta on the laptop (a real upgrade will hopefully overwrite even more damaged files with good copies than I had done before) - and with not having had any of my usual internet access this weekend between helping out friends with a (smaller) fest in town on Friday and Saturday.

It may take me a bit longer than after usual weekends at home to sort out everything that happened in those days - but I'll do it all and nothing important's lost (and yes, I would have backups of all the important data which is on my main desktop computer).