The roads I take...

I've been talking about it in weekly status updates for a while, now it's in a state where I can publicly link it: The Build System Porting Tool I've set up to track changes in the Mozilla build system that (may) need to be ported to the comm-central build system files.

The tool's database knows about over 2200 "changes" (one change per Mercurial revision and file, i.e. one revision touching 3 tracked files create 3 "changes"), and people with edit access to the tool can flag any such change as ignored or ported as well as add a bug report and revision for the port. Currently only site admins have edit access, i.e. that's only me, but the code should be fairly easy to adjust to give other people such access as well (this solution was just the fastest to get the tool working well enough at all).
So, the really large part of the work was to narrow down those >2200 changes and eliminate all that can be ignored (e.g. not needed to be ported, before comm-central creation point, listed on 1.9.1 but before branch point) and mark all that have already been ported, of course with the correct information. Coming down to about 350 changes was easy by ignoring changes by time (branch point, etc.) but then it needed me to take a look on every single change to determine if it needs work. I did this over the last few weeks, and now we're down to just under 190 changes we still need to take a look at.

Serge has been working on a number of those we need to be on par with 1.9.1 recently, to get up to speed with mozilla-central we'll need a good pile of more work - but now we have a way to track all this.

Back in 2007, I was wondering if a mobile device that fits me will ever be built and saw the unveiling of the N810 as a step nearer to that. It was a really open, hackable mobile device, with a Mozilla-based browser, but it lacked phone capabilities, so even when I bought one a few months later, I still needed to carry a phone around with me in addition to this surely nice device.

What I really wanted after all, was a smartphone, albeit one that was truly open and hackable at least on the side of software, reasonably fast, with a Mozilla-based browser that shows the web as it should be and a touch screen in a handy size - oh, did I say it should be a phone at the same time? Would it ever exist? I trusted it would, I was just thinking ahead of the time.

The OpenMoko was a phone that sounded interesting, but it never came to a state where it would have few enough problems to make the mass-market. When Google came up with Linux-based Android, it sounded good, but the G1 and friends are nothing like an open, hackable device. It goes without saying the the iPhone isn't, even though it looks cool and seems to be pretty functional.

Meanwhile, having the N810, I grew quite fond of the nicely sized touch screen, but even more of the maemo distribution, and of many things like maemo-mapper, which is my trusted OpenStreetMap-based travel companion nowadays. And I closely am following the maemo community through blogs, etc.

So, it was no big surprise to me when Nokia unveiled the N900, powered by maemo 5 this week. I've read enough rumors about this "RX-51" or "Rover" prototype device, esp. in recent weeks but even vague comments before that.

And still, it's a bit overwhelming for an open source guy like me. This is actually one of the largest mobile phone producers worldwide shipping a smartphone (yes, a phone!) based on Linux, with a fully hackable software stack and, importantly of us, a Mozilla-based browser! Shipping, as in pushing it out as their top-of-the-line product for consumers! Not just a geek thing like the OpenMoko, a normal consumer device that at the same time speeds up the heartbeat of any open source geek!

This is a bold step for Nokia, and I really hope it will be successful - this could be an important point in getting open software out to consumers, possibly even as large an impact as Firefox on the desktop. Thanks to Nokia for taking this step. This week, I'm really proud to be a Nokia - and maemo - user.

I'm not sure if the N900 is fully the device that fits me in every regard, I fear the screen might come to be a bit small of the things I've grow accustomed to (maemo-mapper, browsing, showing my pictures to people, even doing some programming), and I also fear that the smaller keyboard compared to the N810 makes typing even harder, but in any case, the N900 is another large step to the device I want. I think the fact that it's less a niche product but a general consumer product (even as a high-end smartphone) is overall the more significant matter than if it fits my requirements perfectly.

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 34/2009 (August 17 - 23, 2009):

• Releases:
  After I could fix at least one major problem on the Linux 1.1.x build box (something is still strange with nightlies), I started the release process for SeaMonkey 1.1.18, which has a major upgrade of NSS (and NSPR) as the only major change, which fixes a few SSL issues, including possible MITM of SSL connections. We found a regression on Windows, failing to package some new files coming up with that upgrade and rendering NSS unusable, we're fixing this right now and doing a second round of candidates with it.
  A 1.1.19 in a few weeks will then catch up with other fixes ported from Firefox 3.0.13 and 3.0.14 (the NSS we ship now is exactly the same as in those versions).
  I also filed a bug on 2.1a1 as well as 1.1.19 flags on Bugzilla, we now can mark things we'd like to see fixed in those future milestones.
• Build System:
  Even more review for Serge's patches for porting build system changes to comm-central and and some, but not much progress in filtering out the to-be-ported changes in my new tool.
• Various Discussions:
  Tabmail, Mac build boxes, AMO and SeaMonkey, QA team, www.mozilla.org planning, Mozilla Camp Europe, Mozilla Creative Collective, SUMO browser sniffing, doorhanger notification plans, Thunderbird schedules, etc.

I've been quite busy this week with a halfway-finished move in real life, but things are moving well along even with me not being around as much as usually and I'll be back for the usually amount of time every week when the move is completed.

By the way, I just did get some interesting numbers about SeaMonkey 2 usage: Over the last week, we had ~2700 people average daily users on 2.0 Beta 1, about 500 on the alphas, ~460 on 2.0b2pre builds, ~150 on 2.1a1pre, and ~160 on "pre" version from before 2.0b1 - a total of almost 4000 daily users on our current unstable versions and in August, where many people are probably still on holidays. I think those are pretty decent numbers, esp. as there is a 25% rise in total numbers compared to 4 weeks earlier.

Finally, there is a website up where I can post the wallpaper (and possibly other) designs I made with SeaMonkey imagery!

You may remember my earlier "Knock, Knock, Alpha." post with the Matrix-inspired wallpapers and the recent Mandelbrot app post with that SeaMonkey logo coming out of the Mandelbrot set. Now you can get all those in full quality, comment on them, vote for them and whatnot.



Where? On MCC - the Mozilla Creative Collective!

Thanks to everyone at Mozilla who made that site possible!

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 33/2009 (August 10 - 16, 2009):

• Build and Release Machinery:
  The last step for release automation is done - after the move of CC* release factories to buildbotcustom, we have all the tooling for comm-central-based releases in shared code. We share those classes completely betwen SeaMonkey and Thunderbird release automation in the future, and also share as much as possible with the Firefox process. Because of that, any fixes in the process benefit all of us at once, and we all have the same tools for verification of updates, etc. There should be quite some mutual benefit in this.
• Build System:
  I reviewed more patches from Serge for porting build system changes to comm-central and next to this worked with my new tool described here last week to filter out those changes that still need porting. From about 350 changes last week I could filter the list down to about 230 right now, and that list still needs a bit more work to eliminate changes that we actually don't need to port after all. When I get to finish that filtering, I'll post a link publicly, until then, links are available on personal request.
• Download Manager:
  I did another pass on the "Properties" view patch and now included a test that actually calls it, checks that indeed a progress window comes up and that it correctly gets the end time for finished downloads. The patch got review and could land on Sunday. This patch also fixed the wrong icon on the download manager window, it displays its own icon again now.
• German L10n:
  As reported in a bug, German SeaMonkey 2.x builds had strings overflowing multiple panels in the account manager. I fixed that by both increasing the account manager width and shortening a number of strings. While I was at it, I took care that preference panels fit as well.
• Various Discussions:
  2.0b2 and 2.0 final scheduling, 1.8.1.23 security release, tabmail, new Mac theme, SMILE, QA team rebuilding possibilities, AMO and SeaMonkey, www.mozilla.org planning, Mozilla Camp Europe, Community Store contacts, etc.

Two great features landed this week in the SeaMonkey tree: SMILE and the new Mac theme. While I still hope we'll hear a bit more about them in blog posts on the official SeaMonkey blog, here's a small description of what makes those two items special enough to be highlighted:

SMILE is the SeaMonkey Interface Library for Extensions and is the same as FUEL for Firefox and STEEL for Thunderbird - a collection of APIs or access points that make work tremendously easier for add-on developers and. Starting with nightlies this week, SeaMonkey provides the Application object (as a smileIApplication instance) implementing the common extIApplication functionality and a bit more. Any add-on that uses those functions in Firefox or Thunderbird already is now much easier to get to run in SeaMonkey as well. Jorge Villalobos did the initial implementation of SMILE, Philip Chee finished it up so we could add it now - thanks to both of them for this work! We're still looking for someone who can write up documentation for it on MDC - are you willing to help there?

The new Mac theme is important for completely different yet creatively similar reasons, the common thread is consistency. While SMILE makes add-on interfaces more consistent with Firefox and Thunderbird, this new default theme on OS X make SeaMonkey's look not only consistent with those but also practically all of the modern Leopard desktop. The unified look of the window title bar and the toolbars, their dark look, the look of tabs in the page info dialog, thin vertical splitters and a lot of other things were tuned by Stefan Hermes to make SeaMonkey fit as well with the Leopard style as reasonably possible, even if he says that there's still a few things he can improve even more. I hope he'll do a post with a few screen shots soon so everyone can see how much better SeaMonkey 2.0 looks in Mac style now.

We have about two weeks left until feature freeze for the 2.0 series and we're coming along nicely. Let's use the remaining time and make it even better!

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?

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 31/2009 (July 27 - August 2, 2009):

• Build System and Release Harness:
  Continued investigating the issue with the "hoshi" box that does SeaMonkey 1.1. Linux builds.
• Planning and Feedback:
  I spent a good amount of time with both looking at feedback for 2.0 Beta 1, which look quite positive in principle, but includes a few reports of regressions and bugs that need attention, as well as planning for the second beta and even final. We discussed the latter at the SeaMonkey Status Meeting and decied to decouple the schedule from Thunderbird so that we're able to get the new generation out and can set a stamp on retiring the old one, which is really overdue.
  I also closely followed the planning for an upcoming security update for 1.8-based releases, which will include a SeaMonkey 1.1.18.
• German L10n:
  Some mailnews updates for keeping de sea20x green.
• Various Discussions:
  Windows linking issue, tabmail, new Mac theme, Gecko/platform planning, some XULRunner-based Mandelbrot fun, checkin comment rules, code style discussion, etc.

This Tuesday, Beta 1 has surpassed the ~18,500 downloads we had for Alpha 1 - just that the first alpha had two months of lifetime as the newest development release to gather that amount, while the first beta had two weeks to get up to the same number.

Also, we get repeated reports of Beta 1 working at least as stable as 1.1.x for people, most of the problems people have seem to be related to migration of profiles or regressions we are working on (or even have already fixed in current nightlies). All in all, things seem to go well with the first beta.

As for the second beta, the code freeze for it will also mean feature freeze for the whole 2.0 series, so we need to get the two large missing features - the new Mac theme and tabbed mail - in before that freeze to have them in this series. Things are moving for both though, each of them got significantly nearer to checkin readiness lately, tabmail has been tested for a number of interesting use cases and got its first full pass of code review comments, the Mac theme has UI review now. I'm looking forward to seeing everything wrap up before the targeted freeze on September 1.

This week, I found some more time to hack around on my fun project to do a Mandelbrot set fractal renderer in XULRunner - some of that fun hackery done on the N810, some on my desktop, finally some on my laptop, and now those sources create a really usable application.
The only thing holding me back from doing a downloadable "(pre)release" package of any kind is that it's still somewhat hard to do that for XUL/JS-only XULRunner apps. I'd need to compile my own XULRunner and package it with that or such to get a usable downloadable thing.



What I added this week to bring it over the top was a zoom function that works by dragging the mouse over any piece of a rendered image and a possibility to bookmark locations and call them up again at a later point. With that, one can easily navigate to different places and get pictures like the one above - my laptop calculated and rendered the original 1280x1024 picture in a matter of seconds, with a 1.9.1 XULRunner from some time this weekend, so the same TraceMonkey present in Firefox 3.5.2 to calculate all those iterations, and I did save the contents of the canvas used to paint it as a PNG with the functionality I have in the application. Any quality degradation comes from scaling and converting to JPEG on my web server.

Oh, and there's one more interesting picture I did get out of this work:


(larger sizes linked, original 1280x1024 desktop-wallpaper-ready version available on personal request)

All the fractal pixels in this image come from TraceMonkey's calculation again, of course, but the GIMP helped slightly to finish off this one.

Ich hab den gesamten Samstag Nachmittag und Abend damit verbracht, eine Menge Wald- und Schrebergartenwege in meiner eigentlichen Heimat Steyr-Münichholz mit dem Fahhrrad abzufahren, mit dem N810 mit dabei, um GPS-Tracks aufzuzeichnen.
Einerseits war das eine starke Abwechslung zu meinen sonstigen Beschäftigungen und damit ein geistiges Ausspannen und das Training schadet mir auch nicht, andererseits konnte ich wertvolle Daten sammeln, um OpenStreetMap weiter zu ergänzen.

Das Ergebnis kann sich sehen lassen: Im Kartenausschnitt von Münichholz sind jetzt im Waldstück östlich der Punzerstraße sowie in fast allen Schrebergärten (braune Flächen) die diversen Wege verzeichnet, inklusive Typ der Wege (mit zweispurigen Fahrzeugen befahrbare als brauner "track" mit Abstufung nach Beschaffenheit, kleinere als "path" mit Angabe, ob sie mit dem Fahrrad befahrbar sind). Zusätzlich hab ich das Alten- und Pflegeheim und das "neue" Straßenstück daneben endlich richtig eingezeichnet, sowie einige Dinge im Umfeld aller dieser Flächen korrigiert.

Überrascht war ich, dass entgegen früheren Erfahrungen das Haupt-Kartenmaterial mit Mapnik-Rendering fast in Echtzeit aktualisiert wird (früher passierte das ein Mal pro Woche), sodass während ich im nächsten Stück unterwegs war, die Daten vom letzten Zwischenstopp schon sichtbar wurden und jetzt alle meine Änderungen bereits voll präsent sind.

Andererseits fragte sich wohl so mancher Schrebergarten-Bewohner, warum da einer rumfährt, in alle kleinen Wege reinschaut, auch wenn sie Sackgassen sind, und nirgends stehen bleibt.

Ich kann mich erinnern, dass ich als Kind immer eine Karte der Wege in den Schrebergärten und besonders vom großen Bischofswald bzw. "Münichholzer Wald" haben wollte, und mir dachte, es wäre cool, sowas selbst zeichnen zu können. Einen Teil davon konnte ich mir jetzt per GPS-Empfänger und OpenStreetMap ermöglichen - die Wege im großen Wald kommen sicher auch noch, vielleicht brauche ich ja mal wieder Mal Abwechslung vom Arbeiten, bin bei schönem in Steyr und meine Eltern nicht zu Hause...