The roads I take...

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 07/2010 (February 15 - 21, 2010):

• Releases:
  Released SeaMonkey 2.0.3 on Wednesday - finished up release notes, pushed files, updated the website, created and sent announcements, pushed update snippets to the release channel. Everything seems to have worked fine there and people should have a better SeaMonkey 2 now.
  Unfortunately, my website updates caused a temporary website glitch but I could fix it fast when it happened.
• Build Infrastructure:
  After we dropped 1.9.2 and I turned off the experimental builds we had running with that tree, I turned on Mac and Windows debug builds instead, I found a slight infrastrcuture issue with this and created a patch for that issue.
  Most of the new Mac machines are here and working now, I integrated them into the build pool and they are working really fine - faster than any other Mac machines we have!
  I could also turn on the first few tests on trunk after those machines joined, and it looks like Mac is (mostly) consistent with Linux there.
  One of the new machines still is not really available, once that is online, we'll drop the old VMs and replace them with more Linux and Windows machines on Parallels.
• Places:
  As I did the initial work to get places history to work in SeaMonkey, I feel some affinity with this module. I had done a patch for the new expiration changes earlier, and now as we're only supporting 1.9.3 and higher on trunk, I could land that patch finally.
  I also started to look into places bookmarks support and promptly found that HTML import/export is Firefox-specific code right now, but me and places developers agreed that it should move to toolkit. My current local work is mostly ripping off large portions of Firefox code, the cleanup parts will come once things mostly do actually work.
• Build System:
  I filed bugs on killing 1.9.2 support after we made that decision, and like so many other build system work recently, Serge came up with patches for those. I also reviewed a few build system patches, most of them again from Serge, but including a few others, like OS/2 packaging support.
• German L10n:
  Michael Opitz did another help fix which I could check in.
• Various Discussions:
  2.1 decision for 1.9.3, Gecko 1.8.1.24 and SeaMonkey 1.x EOL, upgrade to 2.0.3, web form management, EOL for Mac OS X 10.4 "Tiger" on 1.9.3, (not) branching comm-1.9.2, "human-readable" pushlog feeds, etc.

After the SeaMonkey 2.1 Gecko decision, I think we're now on a good way to getting actual progress on our code for this next version. Following the platform, we unfortunately will have to drop support for Mac OS X 10.4 "Tiger" as well in that release, but we hope that Mozilla 1.9.1 and therefore SeaMonkey 2.0.* will be maintained long enough to get a large amount of those users transition to newer systems - if they can't afford new hardware, they should possibly look into converting their system to Linux, which is being maintained and which we can support more easily as well.
While we can't change those platform decisions, we can change our own code, and we are currently starting to work on more and more parts of it for this future version - and your help is wanted to improve it even further!

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 06/2010 (February 8 - 14, 2010):

• Releases:
  SeaMonkey 2.0.3 preparation moved along with copying builds to the right locations, creating checksums, etc.
  We haven't heard of anything bad from beta-testing this release, so we are on course for a release on Tuesday, February 16.
• Build Infrastructure:
  This week it was mostly maintenance of the build pools, but it looks like data on graphs server and new Mac machines are coming near to getting finished now, esp. the latter should give us a good boost in what our pools can do (moving Macs from VMs to real machines frees up some space for Linux and possibly even a Windows machine, which we can put up then).
• Download Progress Windows:
  I put a number of additional hours of work into improving progress windows, but finally threw everything away after I encountered just too much stop energy. I felt an obligation to finish the job on those progress windows after I started it and saved their lives in the needed rewrite for 2.0 when the old implementation wouldn't work with the new download manager backend and we needed a new one. After being cursed, damned and nitpicked up to a point where it not only was no fun any more but also was starting to really depress me, I decided that someone else should care about it.
  I had done some work on a further progress window bug but also unassigned that from myself following that decision as I have wasted all my potential to deal with stop energy regarding that part of the application.
• Build System, Packaging:
  I verified or marked two more bugs as fixed that have been resolved by my package manifests merging. Good to see that this went well.
  As a followup, the OS/2 people are getting the manifest for SeaMonkey to work as well, I had some discussions about review and improvements for their patch in the bug.
• Various Discussions:
  Out-of-process-plugins for SeaMonkey, 2.1 planning discussions, Gecko 1.8.1.24 and SeaMonkey 1.x EOL, KompoZer integration work, official listing for comm-central build system module, EOL for Mac OS X 10.4 "Tiger" on 1.9.3, (not) branching comm-1.9.2, automatic delivery of SeaMonkey statistics from Mozilla Metrics, etc.

As told above, progress windows have been a quite disappointing story for me, putting in many, many hours of work for saving a feature in SeaMonkey that nobody else still has and getting almost nothing but stop energy in return. I've been thinking about writing a "how to lose contributors" guide as a blog post, as right in that work we nicely did sum up a number of good mistakes to make if you want to get rid of people who are willing to help. Of course, it won't drive me away from the project as a whole and I can take quite some beating from some time, but in the end, some minor stuff was enough to drive me over the top and throw the towel on that single part of the app. And guides for "how to make things wrong" always make a better reading than advice for how to do it correctly, esp. as there is no single correct way, but a number of wrong ones.
So, keep reading, I probably will write that one up soon here on this blog!

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 05/2010 (February 1 - 7, 2010):

• Releases:
  I prepared SeaMonkey 2.0.3 builds, which are now available on FTP as well as the beta update channel for testing by our community, offering well over 100 bug fixes. If things go well, we should be able to release this update in sync with Firefox 3.5.8 on February 16th.
  The 2.0.x nightlies now carry a 2.0.4pre version number, but we have no firm schedule for the following updates yet (will coordinate with Firefox, possibly also Thunderbird drivers on that).
  Work on 2.0.3 also included putting up a first version of the release notes.
  I also tried to let the release process generate 64bit builds for Linux this time, those are fully experimental and will only appear as "contributed" builds though, they have no official status at all.
• Build Infrastructure:
  The move of our core buildbot master code to a shared location could be completed, Thunderbird will look into using the same code in the future and we closely mirror the Firefox setup now, making it easier for people patching their side to fix ours as well (and the other way round).
  Revision reporting on packaged tests is now both generic and respecting applications that are built from different repositories as the platform (like SeaMonkey or Thunderbird).
  Additionally, I continued working with Mozilla teams to get SeaMonkey data up on the graph server, which needed a firewall rule and a correction on the staging server's database, but testing looks good now and we should be able to go live on the real server soon.
• Download Progress Windows:
  I created screen shots of some additional proposals for improving the progress windows, requested ui-review on them to see which one wins out with our "UI tsar", and finally implemented the winning proposal in a patch, which should be very close to positive review by now.
• Build System, Packaging:
  After a few runs on the Mozilla Messaging try server, I could finalize the patch for merging our package manifests and also make Mac use a manifest, get reviews and check it in.
  Another patch I worked on is about making branding usage fit Mozilla standards more closely, which should also ease the life of people wanting to ship suite versions with a different branding than the official "SeaMonkey" trademark designs.
  Some discussions about build system variables reminded me that I should re-test and attach the papering-over patch for mailnews Qt port bustage which I've had locally for quite some time now.
• SeaMonkey L10n:
  Starting with SeaMonkey 2.0.3, the language packs are marked compatible with all 2.0.* versions.
  Also with this release, Japanese is joining the collection of officially available localizations.
  This was also the first time I played with and used the new L10n sign-off dashboard for a release - further opt-ins / sign-offs for SeaMonkey 2.0.x will all run through this tool now. See the m.d.l10n thread for more details on using this tool.
• Various Discussions:
  2.1 planning discussions, Alpha 1 and further steps for 1.9.3, Gecko 1.8.1.24 and SeaMonkey 1.x EOL, KompoZer integration work, new machines, FOSDEM, places history changes, module ownership, mozilla.org planning and "Mozilla" vs. "Firefox" websites, EOL for Mac OS X 10.4 "Tiger" on 1.9.3, langpacks and switching, etc.

I may not have posted a lot of Mozilla-related blog posts this week, but I got around to do quite some actual work. I wondered for a bit if I should post separately about the progress window work, but the ignorance of hard work I have been and am putting into those tiny windows as well as the vitriol from people who can't stand designs being modernized made me decide not to mention this work much. I know that it needed my work to even have progress windows at all in SeaMonkey 2.0 and I'm convinced that my current proposals and work can fix some of the shortcomings I had already know when doing the initial work and that were criticized by users, but a number of those users seem convinced that our team (especially myself) is not caring about what they say at all, so I don't feel like taking their dreams away. And the attempt of humor in the title of my post about the initial work was not well-received as well. In any case, I feel an obligation to improve work I started, but discussions with those users have taken any fun out of working on this part of the code. Maybe my rare tries of actually doing some coding should stay that rare or even stop completely. It's not like I wouldnj't have enough other work on my TODO list.

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 04/2010 (January 25 - 31, 2010):

• Build Infrastructure:
  I installed a newer gcc on the Linux machines and started using it for trunk builds. Additionally, I synched our mozconfig files for trunk much more to what Firefox is running on trunk as well.
  Because I might be a bit crazy and like to put our machines under more pressure than they should be under, I even tried to turn on one additional test suite on trunk to try and find bugs to fix.
  I also helped Armen from Mozilla release engineering to get his current L10n build work into a shape so that it works fine with SeaMonkey/Thunderbird builds as well.
  Last not least, I filed a bug on disappearing Windows slaves - seems like we've overused the space available on our Parallels server.
• Packaging:
  As we want to run packaged tests on Mac some time, we will need to turn on tests on normal builds there, but need to care that the test files don't end up in file we deliver to users. That and us probably being the only ones who haven't done it yet was enough motivation for me to finally look into merging our package manifests and use one preprocessed file for all (three!) main platforms. I got all the way to having the "browser" section complete, based on the Firefox manifest and our current Linux/Windows ones, now I just need to do the sections for mail and all the other stuff we don't nearly have in common with Firefox - and then get this sucker tested and reviewed!
• Support Emails:
  Even if I tell people that I'm not the person to contact for support, a number of emails about that topic end up in my mailbox nevertheless, some directly, some via seamonkey-council. I tend to move them into a folder and batch-handle all of them every few weeks - or rather months. This week, it was time to do such a pass again, and I sent about 70-80 replies to them (I try to leave nobody without an answer), even though most of those are just one sentence and a templated section to look at our community page to find better and more responsive soruce for support.
• Various Discussions:
  2.1 planning discussions, Alpha 1 and further steps for 1.9.3, Gecko 1.8.1.24 and SeaMonkey 1.x EOL, YouTube and "HTML5 video" vs. Ogg, geolocation service options, new machines, getting codesighs and leak test data on graphs server, KompoZer integration work, L10n dashboard and sign-off, future add-ons UI, etc.

A good part of this week did run into various discussions and more buildbot tweaks, things are moving forward positively from all I'm seeing - we just need to get some more real development done on trunk, even though that slowly starts to pick up now. Any help to make SeaMonkey 2.1 an even better suite than 2.0 is appreciated, of course!