<< Weekly Status Report, W32/2010 | The roads I take... | Weekly Status Report, W34/2010 >>
Weekly Status Report, W33/2010
We're still in the release process for SeaMonkey 2.1 Alpha 3, this week I did a respin for a second build, and later regenerated updates to fix broken Linux update files.
- Build Machines:
After doing the Mac ones two weeks ago, I also upgraded the Windows slaves to buildbot 0.8 this week, now only the master is left on the older version and can be upgraded whenever we're ready.
On our update configs, I applied a small fix that was done for Firefox as well.
When working on the buildbots and also the failed updates, I decided to update the buildmaster to the most-current buildbotcustom code we share with Firefox and Thunderbird builders, and unfortunately introduced two temporary breakages: The log encoding change needed to be reverted because I couldn't figure out the breakage, the test triggering failure could be solved with some tweaks, including a cleanup on Linux slaves.
- Build System:
After I had driven it for some time, I finally landed Neil's fix(es) for xpfe autocomplete building with libxul, which now makes its building being driven from the comm-central side as well, and leaves the the only build breakage of --enable-libxul being in LDAP.
For future major updates from SeaMonkey 2.0 to 2.1 (and probably later ones), it's necessary to send a better platform identifier to the update server, so that we only offer major updates to platforms supported for the newer version - I created a patch and landed it on both 2.0 and 2.1 trees.
The Windows installer needed some changes after being made ready for the future "omnijar" packaging, I fixed a small glitch in the SeaMonkey installer fix that had generously been generated by mwu, who created the Firefox work as well.
A related patch for jar reordering needed a change to config.mk, which I applied to comm-central as well - including a fixup of the command so that L10n packaging works as well.
And as part of my test investigation work (see below), I checked package-compare and found a few small glitches, for which I created a patch.
- Automated tests:
I filed a number of bugs about failures in our tests this week and investigated some some them. All our perma-oranges are hopefully filed now, the fix for one was a places issue (see there), for another, packaging one more new file. The others still need work, and help is wanted. Let's drive our tree to a green state - after Neil has fixed our long-going tabs leak, we can do it much more easily!
I also reactivated the ID test for DOM Inspector after it had been deactivated when inspector was broken.
My followup patches for Neil's post-landing review comments, cleaning up a lot of the bookmarks code, esp. in the manager, could all land after some additional iterations and fixes. One more followup to that is now on file, dealing with access key problems.
For the Firefox side, I tested and uploaded a patch for cleaning up the places library, which ports the applicable parts of Neil's comments back to Firefox code.
Our ID check test found that we were including a bookmark key twice on Mac and Windows, which I fixed by removing the platform-specific binding and using the same, general, one on all platforms.
I also had a few discussions on the add/edit bookmarks panel in the browser, now leading me to believe this should actually be an arrow panel pointing to a bookmark icon in the url bar - which I had left out in my original patches, but now sounds like an even better idea than before, showing if a page is already bookmarked and giving a fast (one-click) bookmarking option. To make the story short, I created a patch for this fast bookmarking button now.
- Tabbed Browsing:
While it may seem slightly unrelated, the patch I created and landed for getBrowser() in mailnews is part of some work I'm doing for the browser to enable site-specific zoom settings, for which I attached a WIP patch that works but generates a strange error when used on the mailnews side.
- Data Manager:
I updated the Data Manager patch for recent review comments, and of course, this only triggered a new round of comments. I also filed followup bugs for further work once this one has landed.
- Various Discussions:
reviews, l10n.mk for Thunderbird, SeaMonkey Development Meeting, user agent string changes, SeaMonkey build machines, GSoC closing up and final evaluations, Firefox TabCandy, work on final look for new addons manager, etc.
This has been a really busy week for me - actually, when writing this up today, it looks even more busy then it felt while it was underway. Unfortunately, we didn't get as far as I hoped on the third alpha, but I hope we'll be able to push it out to the public in the next few days, so our full concentration can be on the beta development cycle. A lot of work has already happened, and some more stuff is underway - both in SeaMonkey-specific code and in the platform, so it feels really great to be in the project right now - even if not always everyone agrees on specifics, but I'm sure we can work out a lot of that to a degree where we all can be happy. And where we still diverge in what we want - well, that what prefs and add-ons are for, after all!
Entry written by KaiRo and posted on August 23rd, 2010 20:52 | Tags: L10n, Mozilla, SeaMonkey, Status | 8 comments | TrackBack
Can we please have a preference to select between a find dialog and a find bar ?
Why should this be the case ? You have the find dialog code in 2.0 and you have the find bar code in 2.1 Alpha 3, it is certainly no trouble to add a preference and use an if-else to call the appropriate routine based upon user preference or are the things that have been written about the stubbornness of the Mozilla people regarding user preference true ?
Another point: doesn't the find dialog code need to remain to support window.find as the last parameter to the function is whether or not to show a *dialog* - https://developer.mozilla.org/en/DOM/window.find
A separate issue: is there some way that SeaMonkey could address the issue with downloaded files not getting the last modification date from the server (bug 178506) ? Again why is there an objection to having a preference for this ?
Finally I hope something is done about the places database handling with bookmarks being moved there. In 2.0 I've noticed that the table moz_historyvisits has several times as many entries as moz_places, shouldn't they be more or less one to one ?
1) No need to discuss the find dialog, it's dead and will stay that way. And a standard calling for any specific UI is flawed and needs to be changed anyhow. Modal dialogs are bad, bad, bad in cases where there's no reason they need to block doing other things.
2) The modification time of a download is a platform issue, we only control the UI, not the platform, so take this up with platform developers.
3) Ask the places team for details, again we only control the UI, not the platform, and the places database is part of the platform. Still, I guess you're just visiting pages multiple times so they get multiple history items but they stay single "places" after all.
Geez could you tone it down with the modal dialog vitriol ? At least in this case it is a matter of personal presentation preference as find is a user-initiated function (Ctrl-F or F3 with no prior find string). Extra toolbars are bad because users want to maximize browser area not have additional toolbars coming up for stuff. Wasn't this lesson learned with the rather intrusive notification bars which have been replaced in Gecko 2.0 with the doorhanger notifications ?
Does SeaMonkey own the files in the SeaMonkey\components and SeaMonkey\modules directories or are they shared with Firefox ? I ask because it would be nice if there was a preference to disable forms autocomplete=off which is implemented in SeaMonkey\components\nsLoginManager.js. Currently I modify the file to disable this "feature" but I have to redo this with each update.