The roads I take...

I've been on a really dense schedule the last days, I hope I'll be able to clear up lots of things now that some bigs steps have been made.

I hoped we would have some time between new releases and the suiterunner switch, but reality wanted it otherwise. This way, both happened only a day apart, and on days where I was studying chemistry with a friend yesterday afternoon (and the day before) as she had an exam today, going out for my weekly Monday/Tuesday Karaoke nights, and having a meeting with my online gaming friends today evening, as well as the Mozpad meeting earlier this evening.

Still, I needed and could find the time to land the suiterunner switch yesterday (which included tree watching and fixups as well as eating dinner on my computer desk while doing that) and get the 1.1.2 (and 1.0.9) release out to the world today.

Ah, yes, right. That's what I wanted to tell you originally. SeaMonkey 1.1.2 is here.

We did a more eloquent announcement for it today, including a paragraph that once again should get the message of SeaMonkey as an upgrade path to Mozilla suite and Netscape 4/6/7 across.
I also did a German version of that message and mailed it out to more IT-related press contacts (in Germany and Austria) than I knew even a day ago. Thanks to #mozilla.de folks for helping me on finding those.

I also got some new download numbers of SeaMonkey, I will probably tell you about those tomorrow, I'm a bit tired right now (3am here in Europe). I probably should already be sleeping, but I still got to look if everything regarding the releases is working as it should and provide Camino folks with some pointer how they can switch over to toolkit as well (they're the last xpfe consumer left on trunk).

It's done.

Or at least I hope so. I have just landed bug 328887 alias "suiterunner", regular SeaMonkey trunk is now built on top of the new toolkit. The first MoFo tinderboxen are currently doing their first cycle of suiterunner builds, and I hope they stay green and tomorrow's nightlies will end up being suiterunner builds.

Thanks Mark for the big load of work you did to get here, thanks Frank for your work on Windows installer, thanks Neil for your uncounted reviews, super-reviews and other work on the road to here, and thanks anyone else who invested lots of time and work into this project.

This is no finish line we're crossing though, it's only the start into the new world of SeaMonkey 2 - and we still have a lot to do in front of us: cleaning of stuff we left behind (mainly in xpfe) and which is now unused, moving over to parts of toolkit we still have excluded right now (download manager backend, places [history], satchel and passwordmanager, to name some) - and, of course, adding new features to premiere in this SeaMonkey release, as well as many other things like cleaning all those rough edges we still have right now.

A big step into this brave new world has been done, and I hope all previous helping hands as well as a few new ones will stay with us on this way we are going and will work on making this suite an even better product than it already is.

Another week has passed, time for the report on my SeaMonkey work in week 21/2007 (May 21 - 27):

• Upcoming releases:
  The target date stays this upcoming week, May 30, we hope Firefox/Gecko don't need a late respin and new RCs. QA on our candidates looks promising, we probably can release exactly those builds on Wednesday.
• suiterunner switch:
  We're basically ready for the real switch, everything is reviewed, the builds should be usable. We'd like to get people's profiles migrated into a really usable state as well, so we've been waiting for better mailnews account migration before doing the switch, see also my earlier post this week. Some migrator fixes have landed on Saturday, the mailnews part just went in today.
  We have no installer for suiterunner yet, we'll probably get the NSIS-based Windows installer in just in time through module owner approval and "post-mortem" re-review, the former of which we just got today.
  It looks like early this week (around the Gecko 1.9a5 freeze) we'll be able to kill off xpfe-based suite and fully turn to suiterunner instead.
• Suite packaging:
  Creating packages from the suite/installer Makefile I did works just fine (yay for the magic of packager.mk). Windows suiterunner tinderbox builds are already created through that.
• Build system:
  Following the increase of modularity in the build system introduced by Ben Turner from Songbird (yay for that!) this week, I made SeaMonkey the first in-mozilla.og-tree application to use it for getting its Makefile generation out from the monolithic allmakefiles.sh and into a separate makefiles.sh in the application directory.
  Yes, the first. Not even Firefox has made this new step so far.
  I'm sure someone else in this awesome community will work on this for those other apps, hopefully soon.
• Killing wallet:
  Got replacing wallet with satchel to a point where password manager works more or less the same as for Firefox and I run into autocomplete problems for the popup needed by satchel. Also, password manager in mailnews doesn't work yet, we're not throwing errors but missing password saving. It turns out that even Thunderbird is still using wallet for that - which doesn't help
• Other code fixes:
  Remnants of content packs have been removed from non-obsolete code.
• Themes:
  I spent lots of time this week on porting over my EarlyBlue theme to suiterunner, after moving to git for managing their "code". I'm finished with the global/ directory and it seems fairly usable on my suiterunner copy so far.
• Trademark policy:
  Mailed the mozilla.com contact, have not yet received a reply from her though.
• Mozpad:
  Missed the first IRC meeting due to my own stupidity, but read the transcript and helped out the channel with my IRC bot and logs. Hope to do better the upcoming week and make the meeting.
• Various discussions:
  Lots of suiterunner post-landing discussions - we're already working on the next steps to make SeaMonkey a better toolkit citizen and embracing the new possibilites; continued Firefox3 UI discussions (this time mainly about unified content handling UI, which I'd like to see going toolkit-global), build system changes, etc.

An interesting observation for me is that every week I get a quite good list here though I always have a feeling that it should be even longer and I should do even more work for this project.

Other feelings tell me in Bill Shatner style to "get a life" - but then, where can I download one or buy it online, and even more, what would I need it for?

Hmm, it looks like suiterunner will not land this week after all, we'll push this out to (hopefully early) next week to fix some problems with the new profile migrator (Mark is working hard on that). It would be nice if nightly testers can migrate their old SeaMonkey profiles to new (suiterunner) nightlies without too many problems - I guess most people won't do that migration too often. So better push out the switch a few days and make that process a bit smoother.
Maybe we get some word about Windows installer until then as well - it really looks like we will be going without an installer for a short period of time though, until the new NSIS installer can land (i.e. we hear some word of Rob or decide to land without review, which is also no good option).

Oh, and I'm away from my normal computer for the weekend, so I won't land anything, esp. not anything that big, until next week.

After establishing the new project for preserving the original Internet communication suite and good success with SeaMonkey 1.0.x and 1.1.x series, the SeaMonkey team is working very hard on creating a completely new generation of this season product - and bumping its version number to 2.0 along with that.

Using the internal codename of "suiterunner", our development team, has been working for almost 1.5 years now on a project officially named "Turn on the MOZ_XUL_APP flag for SeaMonkey", and esp. Mark Banner (Standard8 on IRC) has invested uncounted hours of work into that (sub)project. While it sounds easy on the surface - after all it's just turning on one simple build flag - this means completely replacing a significant layer in SeaMonkey's codebase with different, newer code, which is to a big part derived from our old code, but has evolved a lot to support Firefox and a growing base of other toolkit-based applications.
Looking at a diagram of the Mozilla Platform recently posted by Mike Schroepfer in a recent blog post, one can get a rough impression of what we're doing here, as we're replacing the layer titled "Toolkit" in this graphic. The changes range from the application startup process via extension management to available/supported/different UI "widgets" and touches a really big range of code areas in between.

The good news is that after having experimental builds of such a SeaMonkey version available for some time, we got them working well enough so that we can retire the old xpfe-based suite and replace it with that new toolkit-based variant on the development trunk. Those are still versions intended for developers and may not work as expected, it's trunk nightlies after all - they just make all your data get lost and your computer to explode. Well, even if this might probably not happen, they are still not though for production use and will have many bugs and regressions - but they should be basically usable. Note that we're changing the base toolkit, but we still haven't managed to get everything working with that new toolkit, so we're still not using the same code as stock XULRunner everywhere, we're excluding some toolkit parts and using our old code instead - until we figure out how to get all that stuff done in the new world (wallet and download manager are examples of that).

Still, pretty major changes are happening throughout the code - for users, the new extension management and new profile location are probably the most notable changes caused directly by that toolkit change. But then, we also have the new icon set as a very visible change, and cairo-based Gecko gives us an additional palette of changes. The more we were thinking about version numbers for a release that will result of this work, we realized that such major changes call for a full major version bump, just upping the minor version number one or more steps from the previous 1.1 version wouldn't fit what's actually happening here.
Because of that, we decided that the suite based on Gecko 1.9 will be called SeaMonkey 2.0.

Of course, we are not anywhere near a real release yet, so when the switch to "suiterunner" will actually land on trunk this week, we'll change the version number to clearly tell that this code is still preceding a first alpha of 2.0, or to make this description fit into a version code, that this is 2.0a1pre code.

Still, this will be a quite important step on the road to a SeaMonkey 2.0 - thanks for everyone helping us to get here, and everyone still helping us continue on that path!

I've not been blogging a lot last week, but that doesn't mean nothing was going on. In fact, lots stuff is happening, and I probably spent more time with code than blogging...

Here's a rough report on my SeaMonkey work in week 20/2007 (May 14 - 20):

• Upcoming releases:
  The target for Firefox release has been pushed out to May 29 due to their new RC for 2.0.0.4, which fixed a Firefox-only problem though. QA on our candidates looks promising, we probably can release exactly those builds next week.
• suiterunner switch:
  After some discussion, download manager has been temporarily fixed to use the old xpfe variant until the new toolkit backend stabilizes somewhat. Profile migrator has landed and works well enough for importing SeaMonkey 1.x profiles, even though it still has some rough edges and will be improved later on.
  I did a patch for a suite/installer Makefile so that we can abandon xpinstall/packager with the switch to suiterunner (just got review and checked it in today), and supplimentary fixes for tinderbox configs in the suiterunner bug, which we also need for the real switch, and are still waiting for review.
  Oh, and we're trying to get an OK from Rob Strong to check in NSIS as-is and integrating his re-review comments "post mortem". Hopefully we'll get such an OK soon, and can provide a Windows installer with suiterunner from the beginning.
  That said, the switch is really near, the major blockers are out of the way.
• code fixes:
  Apart from above mentioned suite/installer and tinderbox config patches for suiterunner, I stumbled over "set as default mail app" missing in Windows suiterunner prefs, and fixed that, did a patch for breakpad integration, investigated remnants of content packs and filed a patch for removing them from non-obsolete code - and started to look into replacing wallet with satchel.
• "Source L10n":
  Temporarily using xpfe download manager regressed this a bit, but we're on track for getting this in suiterunner - the German L10n builds from CVS and mostly works (apart from unresolved dependencies of bug 286110 like download manager or wallet.
• Themes:
  Started porting over my themes to suiterunner. Realized that it might be a good idea to import those into another git repository before going too far on this, so that moving around code gets tracked better than with CVS.
• SeaMonkey Marketing Shop:
  Added a sweatshirt and a shopping bag to http://www.cafepress.com/SeaMonkeySuite.
• SeaMonkey slogan(s):
  Posted Summary of votes and proposals - not sure where to go from here (see newgroup posting fro details).
• Trademark policy:
  Gerv told me his contact, from which he hasn't heard back yet, need to mail that contact directly to show someone's actually interested in that topic.
• Various discussions:
  Took part in the big platform discussion, making clear our support of Mozpad, dropped newsgroup notes about interesting things I learned when glancing at the git mailing list (graft, MinGW port installer), Firefox3 UI (if e.g. places is well-thought-through, we could perhaps discuss adopting it later on), different issues about things we still need/want to improve in suiterunner once it has landed, like shell service, debug UI, plugin finder, and others.

I hope we can flip the big switch and can make suiterunner live this upcoming week!

Our Planet lately has been full of XULRunner talk.
And this is good, as it clearly tells that there's wide support of that technology, and things are moving on in that area. While we unfortunately have not yet reached a point where we can magically deploy a common, shared runtime and this vision will not get a reality in the Gecko 1.9 timeframe, the XULRunner platform is growing, and lots of work is being put into it, by MoCo and lots of outside volunteers. This is a cool, open, cross-platform base to builds applications upon, it will get way better even in the Gecko 1.9 cycle, and it will continue to improve in the future. I'm sure of that.

What we need though, is a stronger community around it - not that we lack people working on it or using it, or knowing its internals and deployment, we just can improve a lot in their communication. This helps "users" of the platform (those building apps based on it) in getting better info about how to achieve what they want to do, it helps people working on the platform in knowing what those "users" need to make working with it even easier - and it helps the platform itself by getting patches into it through this collaboration (hopefully also patches contributed back by the platform users).
Mozpad ("Mozilla Platform Adherents and Developers") is a good idea, and we build upon that idea to get such a community started. I hope though that we will leverage existing Mozilla community infrastructure as much as possible there so that it's as easy as possible for people already in the Mozilla communities to participate there.
Daniel Glazman insists in recent blog articles that we need a real name for this runtime, a logo, images "Built with Xulrunner", more visibility on the web sites, and articles in the press. I must admit that I'm with him on that - though I believe, despite I also have heard of other plans - that we should not pick any new name for that runtime/platform. The current, originally temporary, name of "XULRunner" describes exactly what it is - it runs XUL applications, it consists of everything building up the XUL platform - it basically markets the core technology of our platform, which is probably XUL. The majority of XULRunner builds around what is needed to provide XUL with everything it needs to works as expected, so that name serves very well to tell the message that "if you want to use XUL, you need XULRunner". And then, I think the package already got spread widely enough under that name that we should just stick to it, as changing it would probably trash all publicity it already has in developer communities (which are the target audience of this technology, right?). We really need a logo, and "built with XULRunner" images based on it, though. Maybe a good point for starting off the new community.

The SeaMonkey project got some really positive attribution in that recent platform/XULRunner discussion, by the way: John Lilly counts SeaMonkey among XULRunner/Mozilla-platform apps that are doing amazingly well, Mike Shaver is calling our project an excellent example of contributing to the platform, and talks of our success as a volunteer project: SeaMonkey is a great example of a group within the Mozilla community that has shown leadership and motivation in developing, supporting and marketing a piece of software that doesn’t have any Mozilla Foundation employees tasked directly to help it — though some Employees do indeed work primarily in the context of that product as a personal choice, and that’s a fine thing.
It's really good to hear people talk about SeaMonkey this way, it has been hard work to get here, and lots of people didn't believe we could ever get here when we started off this effort.

Oh, and we surely won't stop to work hard on getting even further along. As you might know, though we are using big pieces of the platform building up XULRunner, we still have major steps ahead to get a "real XULRunner app", the efforts for which we have code-named "suiterunner". The major step in that direction, killing xpfe in favor of toolkit should happen really soon now, and we will continue to adopt new technologies present in XULRunner, replacing old, often badly or non-maintained code in current SeaMonkey - without killing the feel of the suite our users have grown to love.
We will continue to be a good example of a XULRunner user, improving this where we can, as this helps both sides: SeaMonkey is a good testcase of an extensive, non-browser-only app building upon XUL technologies, which helps to improve XULRunner as a platform for such products, while we can get out a platform that serves our suite better.
Because of that, the SeaMonkey project will be proud and glad to be a member and supporter of a stronger XULRunner community, helping to make this Mozilla platform the best comparable product on the market.

A Japanese blogger called "Amigomr" seems to be picking interesting posts from the Mozilla blogoshpere and translating it to Japanese to give us a wider audience in Japan. This is awesome - and something that's probably only possible due to the web and maybe the "Web 2.0" phenomenon.
And now, this blogger asked me if he was allowed to also translate my posts - so if it's easier for you to read my earlier post about The Mozilla Platform, Firefox, and SeaMonkey in Japanese, here is the translated article!

I never thought I'd see my own blog posts in a language I am not nearly able to grasp. Again, thanks, that's just awesome.

It has taken us a while, but now it's done:

At http://www.cafepress.com/SeaMonkeySuite we now have a SeaMonkey Marketing Shop where you can get T-shirts, even a mug, mouse pad, or trucker hat, all in a SeaMonkey design!

You can order items there now and spread the word about SeaMonkey visually everywhere you go, in your office or at the breakfast table.

Oh, and here are some pictures of items I bought myself there for testing the shop:

View photo gallery

Oh, and I had to remove the black T-shirt for now, the design I made is to little visible on that T-Shirt, I need to improve this first.
Edit: You can get a virtual black SeaMonkey T-shirt from my alter ego "KaiRo Soon" in SecondLife if you like

All items are priced with a markup to the original CafePress price. We will use this to potentially upgrade to a premium shop where we can offer e.g. multiple white T-shirts with different design or use a much more custom shop site design. If you are ordering so many items that we still have loads of money left there, we'll donate items from the shop to major SeaMonkey developers. So in any case, we won't directly profit from any money there, this shop is purely for SeaMonkey community marketing purposes, to enable you to spread the word more easily.

CafePress offers us several shipping options, including worldwide international shipping, so everyone should be able to get his SeaMonkey T-shirt delivered. If you're living outside the US, note their help about import duties and taxes though, as your country might charge additional money for importing those items.

If you have proposals for additional items we should provide there, please tell us, either here on my blog, in the SeaMonkey newsgroups, on IRC or via seamonkey-council@mozilla.org.

We hope to see lots of people wearing SeaMonkey T-shirts running around this summer, sipping coffee from a SeaMonkey mug in their office or at home...

The recent discussion of the Mozilla platform is really interesting to read. The arguments go from "we need to be more of a platform" to "needing platform tools is bad", and interestingly, I tend to agree with a real lot of those - as I guess will most active SeaMonkey and general Mozilla contributors.

Sounds strange? Actually, it's easy to explain:

For one thing, there's the Mozilla Manifesto, which, even though only taken into words this year, describes what we in the Mozilla development community have already been working for in recent years and we will continue to go with those principles. In a certain way, it's nothing more than the base Mozilla mission of "preserving choice and innovation on the Internet" which always had been there and will still guide us to the future. Because of those common principles, we have similar visions for the future of the Mozilla project, the browser and the web - those those vision vary in their details, of course. But still, there are strong similarities, so no wonder if we agree in principle in lot of topics on "the platform".

And then, "the platform" is multiple different things, actually. There is the Mozilla application architecture, or XULRunner as a platform to build internet software, usually based on XUL and cross-platform (though Camino doesn't follow that exact path and is still based on that platform). As the platform is "only" the backend for application, it probably receives equal or more work but less publicity than the applications built on top of it. Those applications, most notably Firefox, but also Thunderbird, SeaMonkey or Sunbird, due to the rich extension architecture built into them, are another platform though - it's awesome what interesting work gets done based on that extension platform. And then, the web itself is a platform nowadays, and it gets richer and richer. After all, that's what "Web 2.0" is all about. And our browsers are supporting that web platform through a lot of open standards we implement.

So, if we're talking about "the platform", we're probably taking about different levels of that tiered platform stack all at once. And surely we can improve all those - Gecko 1.9 and upcoming Mozilla2 work is directed at improving all those platforms and lots of work on them is happening as I'm writing this and you are reading this. So, Mozilla will be a better platform and we're all working on that, as we know we want that: a better application platform, a better extension platform, and a better entry door to the open web's platform (no, not a platform for the web, but a client for the web platform - the web will never be tied to us, it's much more the other way round). And yes, as shaver points out, you don't need tools to work with those platforms (I'm doing my work on all those platform levels with a simple text editor) - but of course, there can be tools to ease working with them. Still, using a tool means that you give some control of your work to that tool instead of having every single character of the document in your own hands. And you can keep that full control yourself when building on our platform(s).

The difference in those platforms is that we control both the application and extension platforms in the Mozilla community, we can keep them as open as we want/need to fulfill the Mozilla Manifesto we all believe in, and to preserve choice and innovation on the Internet.
The web as a platform is nothing we have direct control of - after all it's way bigger than our own community, it's actually what we build upon (without the web there would probably be no Mozilla project at all), we are only a part of the ecosystem. And there are other forces at work there, which don't follow the Mozilla Manifesto, some because they want to earn their money in other ways than us, some because they want to create web sites and apps that look cool and work for some group only without caring for a wider audience or free choice of clients. I'm sometimes shivering when I see how many "Web 2.0" services depend on the closed Adobe Flash system, for example - which needs specially crafted, potentially expensive, tools for creating content, and a viewer that is still not available for 64-bit systems or minority platforms such as BeOS, from what I know. There are also lots of sites out there that do browser detection and close out any browsers their creators didn't know, even if they'd work perfectly with their content, and so they are effectively closing out users and, yes, customers.

As Tristan points out, Firefox has helped a lot in making the web better, as a standards-compliant browser with 15% market share gives better reasons for people to create standards-compliant web content. And I'm with him that this market share still needs to increase (not by heavily competing with other standards-compliant browsers though, users of non-compliant clients need to be targeted primarily - and Firefox has the right concepts to serve as vastly improved replacement for IE). Unfortunately, web content creators haven't grown more intelligent with Firefox' rising market share though, and so they're still heavily using browser detection, often wrongly looking for "Firefox" in the UA string instead of realizing that Gecko is Gecko and so SeaMonkey, Minefield and other non-Firefox-branded Gecko browser users are often closed out unnecessarily.

And where does SeaMonkey fit into all that "platform" talk? Naturally, we fully support growth of all those platforms. Of course, as a consumer of the application platform, we want to see a good toolkit - and we're seeing our product as a good example and testcase for a non-browser-only app built on this platform, often raising problems there that wouldn't be seen by having only Firefox as a consumer. We are also trying to be a good extension platform, vastly improving this by moving to the new extension management infrastructure of toolkit with our next major release. And, of course, with a heavier orientation on power users, experts and web developers, we're standing united with Firefox in supporting an open web platform, hoping to fill a market niche that our trimmed-down browser-only brother may not reach that well with providing our integrated solution and providing more options directly in the default UI.

I think, in the big picture, that we are all big supporters of all those tiers of "the platform", even though I guess, most of us want their respective part of it to get the most attention. In the end, we all want all parts of it to thrive, and I also see that happen as we work on them together - now and in the future.

In 1998, some brave Netscape engineers came up with the idea of a cross-platform front end, or XPFE for the mozilla.org-developed next generation of their internet suite.

Now, nine years later, some brave SeaMonkey developers will finally kill it.

Actually, that's not quite the truth. Back then, this XPFE or "XPToolkit" was the whole effort of creating a Cross-platform UI Language (XUL) and "make cross-platform user interfaces as easy to build as web pages" - which included the idea of rendering the UI with the same Gecko rendering engine that was/is also used for browser content.
And over the years, all sorts of stuff needed to run XPFE-based applications, including most of the UI itself, was filled into the xpfe/ directory of the mozilla.org source code tree - and that directory became a bit of a mess over time.
When recreating the browser application as Firefox, people decided to sort out that mess and created a toolkit/ directory to hold that reworked and cleaner version of the XUL toolkit that nowadays build the heart of XULRunner, Firefox, Thunderbird and Sunbird, among others. To not disturb the still prime product of mozilla.org when they built up that experiment, only the new application used that new toolkit while the suite continued to use its old version that was soon called "xpfe" internally as it was living in a directory with that name - even though the "new toolkit" is just a reworked version, but still basically the cross-platform front end toolkit for XUL applications - though cleaner and improved with better extension management, among other things.
As I said, the suite continued to use the "old xpfe" code - and that's also what we inherited for the SeaMonkey project, and what our current stable 1.x releases build upon.

On the bleeding edge development trunk, we have been working on the major step of porting the suite over to the "new toolkit" though, and as the future (but not immediate) target for that development is to get the suite running on top of XULRunner, we dubbed this effort "suiterunner".
And this effort is nearing a state where it can take over from the old xpfe-based version and replace it as the main development version. When doing that, i.e. resolving bug 328887 and turning the MOZ_XUL_APP flag on in all trunk builds, the "old xpfe" toolkit will effectively have lost its last big user (Camino might still build it, but not using a lot from it, actually) and so it will rest in peace.

And we are getting really close to that point now: Our biggest problem at the moment is that download manager is broken there, but as we'd like to build our future download manager on toolkit's backend (though with a UI similar to our "old" one) and that backend is probably seeing some major rework in the near future, we might just use something that works somehow for now, and only rework the UI so that it does what we really want when that backend work has settled somewhat.
Apart from that, we basically only have two things we'd like to have for the switch, but which are not strictly required: One is a profile migrator to convert old SeaMonkey profiles into new suiterunner profiles. Most of the work for that is done, Mark is currently sorting out the actual C++ code and mainly the list of preferences we need to migrate. The other is the new NSIS-based installer for Windows, we're only waiting on a re-review from Rob Strong, who did the work on this installer for Firefox.

So, as a conclusion: An intermediate solution for download manager seems to be manifesting itself, profile migrator is almost finished, Windows installer just needs reviews (while the latter two are only "soft", not hard requirements) - and then we can wave the "old xpfe" good-bye and SeaMonkey can officially enter the brave "new toolkit" world!

Wow, actually, this week since my last status update went by much faster than I would have expected. Time really ran through my fingers the last few days and I probably have managed to do less stuff than what I personally expected in SeaMonkey terms - but I know I'm always aiming quite high when it comes to personal targets

There are still some things to report from week 18/2007 (April 30 - May 6):

• Upcoming release:
  Tagged 1.0.9 and 1.1.2 in CVS and created first round of candidates. We're now using litmus.m.o instead of the now unavailable testrunner install we had previously, please stop by in #seamonkey if you want to help with smoketests.
• Created SeaMonkey dev watching page
  This is page on dev.seamonkey.at is mainly there to track CVS tags for the releases, but also recent bugzilla and bonsai activity.
• Bookmarks chrome and "source L10n":
  As I reported earlier, bookmarks chrome wasn't moved to suite/ previously and therefore it was one of the last few blockers of "source L10n" for suiterunner. I fixed this via bug 377799 this week, German L10n for its strings is there for testing as well.
  This means that suite source L10n is now close, still there are some minor things to sort out (bug 377801) - and P3P as well as wallet need to be killed. All the big moving around of files has been finished in this area though.
• suiterunner:
  Ongoing discusssions, including removal of the dependency on xpcom_obsolete, which requires turning off sroaming currently until someone re-starts real work on it. Rob Strong has promised to look at the NSIS patch this upcoming week, no other news on the big stuff though - we still badly need someone with XBL, <tree> and nsIDownload knowledge to work on getting download manager to work.
• Various discussions:
  As usual, many small discussions about a broad range of topics, this time including first parts of a PHP implementation for L20n, suiterunner help, mac theming, palm sync fixes for tinderbox, continuing Mozilla2 newsgroup discussions.

Tasks without progress I want to work on next week (yes, I suck, the two of last week are still on the list):

• SeaMonkey slogan(s):
  Need to filter out well-recieved proposals from the newsgroup thread and get some clue how to decide on which one(s) we will be using for marketing material in the immediate future. For the first round of stuff in our new shop, I'm using the www.seamonkey-project.org URL instead of a slogan though, which redirects to our main project site.
• Trademark policy:
  For posting marketing material, we need to have a useful trademark policy. A proposal is in review with MoFo, need to poke Gerv once again about that.
• SeaMonkey Marketing Shop:
  I hope I will get my test order this week, probably will announce the shop then. I'm still thinking about maybe taking a additional dollar per item, so that we may be able to upgrade to a "premium shop" where we could use more than one design per T-shirt type and more custom site design. And if there would be lots of such dollars of income, we could still donate T-shirts to selected coders.

I've been hearing about git for a long time as I already was following LWN.net closely when all those BitKeeper vs. Linux kernel problems came up and Linus started to work on a replacement. Meanwhile, over just two years, that technology has matured enough that it's being used by a wide rage of projects nowadays.

While the Mozilla project will use Mercurial ("hg") in the future, I suggested trying git a few times and probably annoyed decision makers a bit with that, but our big problem is that we need decent support on Windows, and git is not there yet (even though current development looks promising for the future). Mercurial is probably a good choice as well, interestingly it has been started about at the same time as git for practically the same reasons - and it's probably compatible in multiple ways: Not only are both distributed version control systems (DVCSes), they're both using SHA-1 hashes to identify revisions, and even screen shots of their graphical tools look similar.

In any case, I've personally never used anything else than CVS, and that aged, centralized, per-file version control system has served me well for my private projects. I understand its usage as well as its repository quite well and I hardly ever run into its real problems like file moving or such.

That said, I always found git's concept of tracking content instead of files interesting (that's why file moves are more or less irrelevant to it), and tracking changesets instead of single-file-changes could also prove useful in my personal projects. Oh, and then there's one thing that really attracts me about DCVS solutions: I'm doing lots of work when I'm on a train without a net connection, history can prove useful to have there, as well as tracking several different changes to a single file - and then I'm merging this to my other computer and two production systems (or actually, checking in to a central repository and check out on those systems, in the CVS model). And then, learning new technologies is always a good thing.

So, I had enough reasons to try out git for my personal projects, and I spent about 6 hours today figuring out how to work with it, a set of directories I wanted to import, and how to import those from CVS. So far, it looks like everything has worked. Oh, and the PHP code generating this website and blog (the CBSM system) is now running off a git checkout.

After some time of working with this, I'll see if I want to git even more code into such repositories - for now, let's see how this works out

As I've just been reading about what you can do with a Mac mini, I can't resist to show you people this one...

What do the two pictures below have in common?



You might not have guessed it, but both show Phlox. While the one on the right is a Star Trek: Enterprise character, the one on the left is my Mac mini, which I actually named after the former.
Oh, well, and both are somewhat alien to me, though in the meantime, also somewhat familiar.

OK, right, that picture with the Mac mini sitting on the floor surrounded by that "apple family" does not show what I'm actually doing with that box. Well, unfortunately I have no picture of that. It's sitting in some youth center in my home town of Steyr - and it's compiling SeaMonkey continuously. Working 24/7 as a so-called "tinderbox", it's pulling and compiling 1.8.0, 1.8 and trunk trees and building nightlies for the former two and suiterunner builds for the latter (and reporting to the Mozilla1.8.0-SeaMonkey, Mozilla1.8-SeaMonkey and SeaMonkey-Ports tree pages). Oh, and it's been doing all the MacOSX release builds (and candidates) for SeaMonkey releases so far.

Another Mini going strong

Given that Apple box does "nightly" builds every day and is named after a (virtual) doctor, I just wonder what people mean with "An apple a day keeps the doctor away"

While working on buiding candidates for the upcoming SeaMonkey releases, I realized I need to watch CVS tags in pre-release times so I don't miss to update our release tags and candidates whenever a new Firefox/Gecko RC is made/tagged.

As I don't like to manually do that (I'm sure I'd forget to do it), I figured it might be a good idea to make a small webtool to check client.mk for tags and display them - and I have that SeaMonkey Dev page from logo contest times anyways.

While I was at it, I also added our bug radar queries - and then I found it might be nice to get a bug list from the bonsai changes of the last 48 hours as well as a list of the last filed bugs in the SeaMonkey Bugzilla product. All that ended up at the front page of http://dev.seamonkey.at/ now, and all watches are updated 4 times a day as the server load allows. I'll use this for sure, at least around release times - if someone else finds it useful as well, feel free to take advantage of that tool!

When blogging about old Mozilla suite users in March, I presented a few numbers of the www.seamonkey.at website, which is the center for German localized access to SeaMonkey info and downloads, and which contains the default start page for German localizations of SeaMonkey and Mozilla suite.

Since then, SeaMonkey numbers continued rising there, and Mozilla suite usage decreased significantly - and I did some graphs for stats of that page. Counting most hits on the page (this omits some design imagery that bypasses my CBSM system to improve performance), here are some current graphs, including complete April 2007:

Absolute numbers:


Percentages:


Note that any other than the 4 represented browsers are way below 1% and would only give flat lines at the bottom. (Oh, and in June 2006 I had some server problems, that's why absolute numbers did temporarily drop there.)

As you see, Mozilla suite is falling rapidly nowadays that they get scary warnings on their start page (at least in the German L10n), SeaMonkey is increasing well in percentage, but slowly in absolute numbers. As April has 30 days and March had 31, the actual increase is a bit better though, I calculated a 6% increase in daily average of SeaMonkey hits.

Breaking down Browser percentage by versions gives SeaMonkey 1.1.1 a lead with 20% of all site hits, followed by Mozilla 1.7.12 at 14% and 1.7.13 at 8.5% - older Mozilla suites continue to dominate the list: 1.7.3 6.5%, 1.7.5 4.4%, 1.7.11 3.9%, 1.6 3.7%, 1.7 2.8%, 1.7.8 2.6% - a lineup only broken by SeaMonkey 1.1 at 4.3% of all hits. Clearly turning on the update notification alert in SeaMonkey has made people more willing to upgrade to current versions than they were in Mozilla suite times without that alert. Still, summing up all 9 SeaMonkey 1.0.x versions leads to a significant number of 12.6%, so some people seem to have just turned off the notification, even more visible as 1.0.8, which came out when 1.1 was already available and at the same time as 1.1.1, only ranks with very low 0.31% of those hits - way behind Mozilla 1.5 or 1.4 and at the same level as Mozilla 1.2.1 (the last version that was available on MacOS 8/9)!

So, all in all, SeaMonkey's update notification is clearly helpful, old Mozilla suite is dropping, and SeaMonkey is slowly rising. We need to do better in getting 1.0.x users to upgrade to 1.1.x though, and we need to get more publicity overall so we get total hits statistics (SeaMonkey+Mozilla) to rise again, as they're currently decreasing significantly every month. Basically positive trends, but still a lot of work to do!