Weekly Status Report, W26/2009

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 26/2009 (June 22 - 28, 2009):

• SeaMonkey Build/Release Harness:
  Followup work on getting SeaMonkey release automation (also has wiki documentation now) from testing into production to actually work is continuing. The main bug now has the SeaMonkey-specific configuration files attached for review, I tried to make repack independent of ChatZilla or venkman being enabled (doesn't correctly work yet, though), filed a bug and (trivial) patch for pretty names in Windows installer and added shipped-locales files to both trunk and the 2.0a3 release tag (release automation needs to fetch that file from the last release to determine what to generate updates for). The removed-files.in fixup I wrote up after analyzing update verification logs from the release harness has landed, which should also make us ready for shipping static builds in nightly updates.
  I did a small update to the patch for DMG unpackaging in the buildsystem and updated the patch for repack factory abstraction once again for some bitrot from buildbotcustom changes.
• Release Process:
  SeaMonkey 1.1.17 has been released on Monday, containing a good number of security fixes compared to 1.1.16. I continued uploading contibuted builds as they came in.
• Download Preferences:
  As I start to see more and more people being confused about the behavior preference on the download panel not working I started the work on updating the download preference panel to reflect changes from the download manager switch. This will focus on making the behavior and location prefs work correctly so that 2.0b1 will behave itself, more improvements can be done in later followups building on this.
• Bug Triage, Support Mails, Start Page:
  I spent some time looking at bugs that were changed again after the large NEW->UNCONFIRMED change, trying to get actions to happen where possible, or deciding to WONTFIX them in a number of cases (such decisions need module owners or Council members in most cases).
  Also, I finally came around to work the backlog of support mails I had in a subfolder of my inbox (I don't feel responsible for support, so I push them in there, but try to at least give some reply with pointers when I come around to it - might take weeks to months though). I ended up writing 70 replies in 4 hours, taking 3:30 minutes per mail, mostly with standardized replies, sometimes one or two sentences containing more specific help.
  The "start" page on the SeaMonkey project website has been warning people that their alpha/beta builds were outdated when they were older than four weeks which is not the best idea in the light of e.g. Alpha 3 being four months old and still "current" right now. I finally came around to modifying the page to restrict this warning to nightlies and doing a special warning for non-current alpha/betas.
• German L10n:
  Fixed some ChatZilla and general SeaMonkey strings to keep the de locale green.
• Various Discussions:
  Checkin for packaged tests uploading glitch, DEL and other keys in download manager, OpenWebCamp Vienna, Parallels VM adjustments, FF 3.5 release preparations, Scheduling of Mozilla's Weekly Update Meeting, thundertab restore and SeaMonkey, etc.

I have a very strong opinion about how successful our planning of SeaMonkey 2.0 Beta 1 in sync with Thunderbird 3.0 Beta 3 went - and believe me, there's nothing positive on it. Since we defined a freeze for our first alpha, we have learned that only a definitely scheduled freeze date will bring people to pick up speed and concentrate on the really needed stuff for that release. Sure, there's a lot of stuff to do in general, but usually only a few items that really need to go into a release. Most people fail to deliver on those things unless there are deadlines for making it happen. Thunderbird 3.0 Beta 3 is a glaring failure in that kind of scheduling, and with making SeaMonkey 2.0 Beta 1 dependent on that milestone, we ended up with a miserable performance on scheduling and delivering ourselves. If we had know how long that short delay would take, we might have done an Alpha 4 just before the download manager landing and still would be ready to wrap up the beta right now.
In any case, I'll propose uncoupling this beta from the Thunderbird cycle, set L10n and code freezes to happen soon and deliver SeaMonkey 2.0 Beta 1 within the next few (meaning really few) weeks, independently if Thunderbird ships a Beta in the fifth month after their most recent one or not.
We'll set freeze dates at this week's SeaMonkey Status Meeting and follow up with posts on the relevant groups and lists.