The roads I take...

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 08/2009 (February 16 - 22, 2009):

• Release Management:
  I started the SeaMonkey 2 Alpha 3 release process with tagging and building a first candidate, it looks like we need a second build though.
  Triaging approval requests for things to land and then tagging and building the release builds themselves as well as caring of the version updates needed elsewhere took a lot of my work time this week, actually.
• Conferences:
  As the call for papers for Linuxwochen in Vienna ended this week, I spent some time on summarizing what I'm planning to talk about there ("The Open Internet And Mozilla").
  Additionally, I spent some time preparing for the Lift09 conference I'm attending as one of Mozilla's representatives there.
  Oh, and I've been asked if I want to attend the MAOW in Berlin in March and maybe give a talk there. If so, would something like "Porting Add-Ons to SeaMonkey 2" sound interesting?
• SeaMonkey L10n:
  I processed experimental language packs for SeaMonkey 2.0 Alpha 3, looks like we can ship 13 of those this time.
• German L10n:
  German SeaMonkey was kept up with trunk, so that Alpha 3 can also have a well-working experimental langpack.
• Various Discussions:
  Tabmail, (un)forking of mailnews files, HTML5, etc.

This status update is not as long as usual, both due to the a3 release having taken up quite some time and due to me having an early flight to Geneva for being on Lift09 most of this week, and I actually need to get up in less than 4 hours, which is all of possible sleep I can get this night. I hope I'll come back from this conference with lots of ideas and inspiration on the future and Mozilla's as well as SeaMonkey's roles in it!

I just spent nearly 2 hours replying to about 60 support requests either I or eamonkey-council@m.o had received via email, some of them (esp. the personal ones) being up to 4 months old. And once again, I'm feeling more powered out after that time than if I had been working on code or something else that would be really productive. In addition, if there was a handful of requests I really had a good answer for, it's much. Most of my replies to those mails are "sorry, I don't know myself, please ask the community" - followed by a paragraph pointing to the SeaMonkey community page which I c&p from a template.

I'm not the best person to contact for support. And neither is the SeaMonkey Council - thanks to Karsten for handling the vast amount of such mails arriving there, by the way. Without that help, I'd probably have more than double the amount of work with this.

Sorry to anyone who gets late replies on such things from me. But then, I'm not much help, people in our community know so much more about all kinds of problem and questions. You don't want to ask me for support when you encounter SeaMonkey problems. Really.

(Oh, and bug as well as feature requests should be directed at Bugzilla. Don't expect me to fix or report your issues.)

Meanwhile, I'll try to coordinate the project, get people to work on our software and hopefully others to use it, and I'll try to communicate with all the other projects we're working with so that SeaMonkey can continue to move along. I hope that way things work for all of us.

I posted earlier about the legendary "Amazing Fish Cam" operated by Netscape.

Back in 1994, Lou Montulli started this second live camera on the web in the offices of that then-unknown small startup company, and subsequently, an "Easter Egg" was planted in the crazy new "web browser" product they developed, so that it would show live images from their fishtank when you pressed Ctrl+Alt+F in that software (Netscape Navigator). All they did was to make the browser go to the fishcam website, but at that time, something like that was truly amazing (today, people probably would call it the "Awesomecam" or so).

The fishtank and the cam watching it, as well as the "Easter Egg" all were kept alive for a long time, the latter being present in the Netscape Communicator suite and its open-sourced followup, the Mozilla suite, the former operated by AOL even after the acquisition of Netscape and the layoff of the Netscape team.

Even SeaMonkey inherited the fishcam "Easter Egg", but AOL finally turned it off some time in 2008, so we have been looking for a replacement for some time, not wanting to let a legend die.

Lou Montulli was apparently thinking along the same lines when it came to the cam itself and acquired a domain name for setting it up again, and informed us about it with a comment on my blog post about its death. I exchanged a few mails with him since that time and last week he had some info and pictures up on the site, so we switched the shortcut on the trunk nightly builds to point there. Last night, Lou informed me that he has a new camera up now so the image quality is much better.

So, where is it? How does it look? What fish are there?

Check it out yourself:

Rebirth of the Amazing FishCam @ fishcam.com


As it's Lou's work, I think it really can claim to be "the oldest camera site still in existence".
Of course, readers of this post will have a lot of ideas what can be improved or whatever - keep in mind though that changing what's up on the site is not up to SeaMonkey people, we merely have a one-liner in our code that points there, Lou is the one operating the site and the fishcam itself. And remember that he just did set it up again and it's a just a fun project.

Thanks to Lou for keeping the legend alive, we're proud to be able to link to it from SeaMonkey - after all, the fishcam fits quite well with that brand name we have now!

As you might know, a community project like SeaMonkey always needs help from everyone who can contribute his or her time - and testing our alpha/beta versions, release candidates, and development (nightly) builds as well as reporting bugs are the first steps to doing that.

As a reader of this blog, the chance is high that you know that already and have read our web page on getting involved already. You might very well have the time and ability to help even more, but the information on developing Mozilla may sound too scary as the next step.

If that's the case, here are a few options where SeaMonkey really can use your help and that might be good entry point to becoming involved somewhat deeper:

• Bug Triage:
  Our project has inherited a large list of bug reports and enhancement requests from the previous Mozilla suite, and we also get new reports from people who only start with getting involved now. You can help sort out which of those reports in Bugzilla are really helpful to developers, so that those can find the things to work on more easily.
  We're basically tracking two list of reports right now and keeping a third one in mind:
• unconfirmed bugs need your help in finding out if they contain useful information at all (set to RESOLVED/INCOMPLETE if not), do actually apply to our product (adjust product/component if they're about other Mozilla products, RESOLVED/INVALID if not), are duplicates of other reports (mark as that if they are) and can be reproduced (RESOLVED/WORKSFORME if nobody can do so). If they actually are useful and valid bugs, their state should be changed from UNCONFIRMED to NEW.
• Bugs in the SeaMonkey::General component should be sorted out into other components or products. That components is a catch-all for people who don't know where to put their reports, ideally it should not hold any bugs any developer is really working on. You can help in finding the right place for those reports to live in.
• A somewhat scary list we're keeping in mind is bugs not changed since the SeaMonkey project started. We inherited that quite large list from the old Mozilla suite any many of those just do not apply any more the SeaMonkey and therefore can be resolved as INVALID or INCOMPLETE. Still, someone needs to do the work of actually looking at them to find out if they still apply and do that cleanup of resolving them.

Help Content and Documentation:
We have a number of help content updates we want to have in SeaMonkey's collection of inline help by the SeaMonkey 2 release, if you can help writing that up, it would benefit a good number of users.
Extending Mozilla Developer Documentation is of course appreciated by all Mozilla-based projects, including SeaMonkey.

Automated Test Cases:
SeaMonkey is using the same automated testing frameworks as Firefox nowadays, but we lack test cases for most of the SeaMonkey-specific code. We are very much in need of developing more tests and doing that is a very good way of learning how our code works. This makes it a win-win situation: You learn how all this works and should work and help the whole project to ensure that it keeps working correctly even as our development moves along.

Good First Bugs:
If you want to dive in even deeper and are looking for real bugs to fix, there is a list of reports with [good first bug] in the status whiteboard which should be things you should be able to pick up easily enough. We'd really appreciate if you can come up with patches for them and we are around in #seamonkey and #maildev to help you figure out how to do that.
Developers, if you come around bugs that should be on that list, please add this marker!

Helpwanted Bugs:
If you're looking for even more bugs that need help, there is a list of bugs with the helpwanted keyword, which is set where module owners or peers would really appreciate someone from outside their group to help. It looks like some of those are old enough though that you might want to see if they are still valid and useful, and triage them accordingly before starting work on them.

I hope there's something for you in those areas, we'd very much appreciate any help we can get in any of them.

You can make a difference and improve the SeaMonkey suite. Yes, you can.

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

• Build System:
  Due to some recent changes, we had broken extension langpack packaging in two ways, I fixed one of those cases and also checked in the other one.
• Release Management:
  As SeaMonkey 2 Alpha 3 is nearing and we are in a freeze for that pre-release now, I looked into a number of requests for approval of patches to still land for this milestone, granting all of them so far, as they were good fixups and things we want to get tested on this alpha. We're now down to a state where I don't think there's much, if anything, left to still land at this stage. I also looked at our buildbot configurations somewhat but I'm not sure yet if I feel confident enough that I can get buildbot release automation to fully run this week, so I might once again go with the set of scripts I used for Alpha 2, esp. as we still can't ship L10n builds this time (see below).
• Misc Development:
  As the old fishcam is dead, I switched our Crtl+Alt+F easter egg to the new fishcam site operated by Lou Montulli, the inventor of Netscape's original "Amazing Fish Cam". Thanks Lou!
  I also investigated a session restore leak that we found to be fixed by a cleanup patch I later landed for Misak.
• German L10n:
  Once again I brought German SeaMonkey up to sync with trunk, and I also fixed an accesskey problem in the add-ons window.
• Various Discussions:
  Tabmail, (un)forking of mailnews files, KompoZer and Composer, FOSDEM aftermath, toolbar/menubar customization, 3rd-party requirement for commit access, etc.

As we're wrapping up SeaMonkey 2 Alpha 3, it's time to take a look at what larger things made it into that release that should be tested - and which still didn't.
Early in this alpha cycle we could land places history, including storage of way more history entries with good performance and the new smart location bar autocomplete algorithm, which is said to be "awesome" for a number of people. We also could switch to the new login manager instead of the old "wallet" for password management, which shouldn't be much visible for user other than that we have reduced the number of modal dialogs and being able to remember password-only logins. A feature that probably will be appreciated by many users is toolbar customization, which now fully works for the browser component, extending it to at least mailnews, maybe more, is planned for the near future. The last large feature to go into Alpha 3 was session restore, enabling users to get back your windows and tabs after crashes and restarts of SeaMonkey.
The new download manager unfortunately couldn't make it yet, some work to switch the backend is still missing. Unfortunately, that also means that localized builds are still broken, but we'll ship experimental language packs once again for Alpha 3. Feed preview and tabbed mail both still need more work and are also still missing from this milestone, same for Mac theme improvements and full adaptation of Modern to SeaMonkey 2 - for the latter, we're still looking for someone who understands both our review process and theme CSS work to drive the existing work for it into the tree. We'd also appreciate if someone could help with OpenSearch support or else that one will not make SeaMonkey 2.

All in all, there are enough large changes along with the usual list of smaller changes and fixes that SeaMonkey 2.0 Alpha 3 should be interesting to test, but the list of things to work on is still significant. There's still some work to do on larger features, and of course a good number of cleanup tasks for the beta and final phase of this major release cycle, but it looks more and more manageable and I trust we're on the right way to an exciting SeaMonkey 2 release.

The future begins in summer 2009!

A few months ago - actually somewhat more than half a year - we had a guy called "Misak" join the #seamonkey channel, asking if SeaMonkey would have a session restore feature that would bring back your tabs after a crash or restart of the suite. We didn't have that implemented, back in typical open source manner told him we'd be happy if someone (he?) would port the code that already does that from Firefox to SeaMonkey, as it should be fairly compatible. His rely was that it's been quite some time that he did programming work and he was unfamiliar with Mozilla code, but he'd be willing to try doing that work.

On May 4th, 2008, Misak Khachatryan had made the first step and attached a first patch to the 5-digit bug that had been open for that suite feature for 8 years before that already. It took a number of additional iterations, integration with SeaMonkey's different restore-closed-tab implementation, almost 100 more bug comments, long waits for reviews from busy-with-real-life community members (sorry!), another bug for porting more work on top of that (the Firefox code is somewhat of a moving target as well) and all in all about 7 months - but:
SeaMonkey session restore has landed a few hours ago!

There are still a number of followup issues to fix, like a test leak caused by this landing, ported tests for the feature itself, fixups/improvements to the ported code, and original SeaMonkey twists like restoring more than just browser windows and tabs, all of which can be worked out by Misak and anyone else who wants to help us there, step by step. Still, it looks like SeaMonkey 2 Alpha 3 and later will ship with this new feature - and everyone can profit from one guy "scratching his itch", so to speak.

Thanks to Misak for doing this work - and to everyone who also is not familiar with our code yet but knows something (s)he'd like to see fixed: Take this guy as a model and try to make what you'd like a reality - we're surely happy to help you get on your way and get your code into our tree!

On FOSDEM, I had a quite interesting talk with Kazé, who's doing KompoZer, the continuation of the standalone Nvu website editor. So far, the focus has been mainly on maintaining and fixing the application based on the old Gecko-1.7-based core, with a lot of bug fixes to make it more usable and smaller additions.

Now, Kazé has announced the first alpha for KompoZer 0.8, mainly consisting of a port to Gecko 1.8.1, which makes it come along at least to a version that still gets some kind of security fixes - and apparently more stable, to cite the announcement:
This is good news for all users of that application, for sure.

Even more good news, even for SeaMonkey is coming in another cite from that announcement:
Actually, that was also what we were talking about in Brussels - Kazé thinks that it's probably a good idea to port the KompoZer code "back and forward" to SeaMonkey Composer on Gecko 1.9.1 and create a standalone editor as well as the future version of SeaMonkey Composer from that same code, which would help both of us: Him because he can have his being code based on the most current backend, get that code reviewed and has a chance of getting changes into Gecko and the toolkit, and us for getting new features into Composer and having that part of our suite maintained.

This all isn't final yet, but it looks like it's a good option for both sides and results in a win-win situation. I hope we can move forward with this option and get a modern website editor both as a standalone application and as a part of SeaMonkey.

Update:
One thing I forgot to mention above is that active work on the editor and even more the editor UI probably also will have a third winner: Thunderbird. The HTML mail composer uses parts of the same code and probably can profit from active work on this code as well.

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 06/2009 (February 02 - 08, 2009):

• Build System:
  My patch for faster builds got approval and is now in 1.9.1 as well, I hope depend builds are really faster again now.
• Website Work:
  I did some work to finally get the download pages on www.mozilla.org redirect to the project list. This has been a long-going story and it's nice to see it finally resolved.
• FOSDEM:
  Most of the time time week was occupied with work for FOSDEM, be it creating the slides for my talk, or the traveling to Brussels and actually attending the conference there - including its usual overloaded network.
• SeaMonkey L10n:
  Argentinian Spanish could be added as the 23rd language to SeaMonkey trunk.
• Various Discussions:
  Tabmail, session (re)store, feed preview, release schedules, FOSDEM, SeaMonkey vision, toolbar customization, Vista theming, etc.

The FOSDEM weekend went well despite the cold I caught right before traveling there, my talk wasn't too well-attended but probably that had to do with the fact that it was at 9am after a Mozilla dinner the night before. There weren't many reactions to the new SeaMonkey vision, which I count as a sign that it's basically what most people expect of us. I got to know a number of new people, met again with a number of folks I've met a few times already, had some fun and some very interesting talks about Mozilla, SeaMonkey and a few other things. I hope the results of those talks will be visible in some way, and I'm looking forward to the next FOSDEM!

In my talk on SeaMonkey 2 & The Vision Beyond today at FOSDEM, I showed the new SeaMonkey vision to people for the first time. This version basically a near-to-final draft, which we are planning to put up on our website soon, but I think I should bring it to you in this blog right now as the earlybirds who were up and here at 9am have heard and seen about it as well.

After our initial goals of making the suite survive and porting it to toolkit have been reached or are being reached with SeaMonkey 1.x and 2 respectively, it's time to have some guidelines for the future of the project. There are a few balance acts in there where the detailed decisions are to be made by the SeaMonkey Council and module owners on a case-by-case basis.

The topics, integration, configurability, innovation, security and stability are not ordered by importance but are all at the same level and taking up the same space in the project, but it wouldn't be good for readability to display them in the same space at the same time.

Here's the actual (draft) vision text:

• Strengthen and improve integration of the core SeaMonkey components with each other, as well as with optional components and add-ons
• Despite the software having a technical split into components, SeaMonkey should feel as a single application with tightly connected features.
• Browsing and messaging are the primary parts that need to be tightly connected, but optional components/add-ons like web tools, calendaring and others should also feel like they are an integral part of the application once they are installed.
• We should investigate an "everything can be a tab" metaphor that spans not just websites in the browser, but messages/conversations, application parts (preferences?) and anything else that sounds reasonable, possibly all running within a single SeaMonkey window.
• The user experience should be consistent in all parts of the SeaMonkey application, including a set of preferences that affects all those components at once.

Provide choice to power users through a reasonable set of configurable and customizable features paired with extensibility through add-ons

Power users, being one of the main target groups of SeaMonkey, should be able to choose what functionality they want to use in what way.

At the same time, the amount of options must be kept comprehensible for users that are not yet accustomed to everything SeaMonkey has to offer and managable for the team writing and maintaining the code.

Development of SeaMonkey add-ons should be made as easy as possible, for example through providing similar or the same APIs as Firefox and Thunderbird for add-on developers.

Everything normal SeaMonkey users need to tweak should be available in UI preferences, things only a small minority of very advanced users want to change should not be in standard preferences UI.

Add-ons should be able to easily extend, configure and customize functionality.

Continually evolve SeaMonkey and both foster and integrate innovation on the Internet

The distinctions and strengths of the SeaMonkey suite need to be deepened and made to stand out more to make the suite a compelling offer for people.

SeaMonkey needs to keep up with changes in how the Internet is used and should also innovate new ways of using it.

The user interface should evolve gently but steadily to feel familiar to both long-time suite users and people switching from other applications to SeaMonkey.

SeaMonkey needs to master the challenge of combining new uses and workflows with accustomed user experiences.

Protect and enhance security and privacy of SeaMonkey users as far as possible.

Individuals' security on the Internet is fundamental and cannot be treated as optional. (see The Mozilla Manifesto)

The suite needs to offer its users realistic options for understanding, accessing, managing, combining, sharing and moving data created by or about them.

When a feature that provides more security threatens to invade privacy (e.g. sending some of the user's data to a server to check for possible security risks), this effect needs to be minimized, both weighted against each other for default settings, and an option to disable this feature must be provided in some way.

Keep the SeaMonkey user experience stable and mature

The SeaMonkey user interface should be kept familiar to former users of the integrated Internet suite.

Apply "constructive conservatism" to the user experience - don't revolutionize and don't deny change but evolve it in a controlled way.

SeaMonkey should be practical and simple enough for beginners as well as able to adapt/adjust for more experienced users.

"Stable" SeaMonkey releases should be tested well enough by the community that we can trust they feel mature enough for production use.

I hope those guidelines can safely take SeaMonkey to new destinations in the future while keeping up and deepening the strengths and distinctions of what the suite is about.

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 05/2009 (January 26 - February 01, 2009):

• Build System:
  I did another buildsystem port as well as a followup fix to it, and I also updated the L10n Makefiles. We should be better in sync with the Mozilla 1.9.1 build system now.
  The patch for easier default profile L10n also saw a slight update but is waiting for review now.
  The work Callek did earlier for GLOBAL_DEPS (and which I ported to comm-central) made the build system rebuild "the world" (i.e. the whole build) when autoconf-mk changes, which is basically a good thing as we now catch all variable changes there without needing to clobber. The problem is though that every run of configure regenerates autoconf.mk and so causes such a rebuild right now. I found a solution to this now so we will only cause rebuilds when autoconf.mk did actually change. The comm-central part has landed, but the Mozilla part still needs review and 1.9.1 approval.
• Download Manager UI:
  A last patch for the new download manager UI before having the backend is ready now. I hope we can close the gap and get the backend ready soon so we can switch to this for Alpha 3.
• SeaMonkey L10n:
  Added Romanian to SeaMonkey as well as support for Japanese ChatZilla/Venkman.
• German L10n:
  Did some updates to match current trunk development, orthographical fixes and some accesskey corrections.
• Various Discussions:
  Tabmail, session (re)store, feed preview, release schedules, FOSDEM, SeaMonkey vision, Lightning, toolbar customization, etc.

I'm preparing a build with tabmail, feed preview, and session restore, possibly even the new download manager, for doing a demo this upcoming weekend at FOSDEM, I hope people will be awake on Sunday morning to see both that and the new SeaMonkey vision I will be presenting.
I'm looking forward to meeting many Mozillians as well as people from other projects in Brussels!