1. First and foremost, we finally shipped the long-awaited Camino 2.1, bringing a significant under-the-hood upgrade to all of our users, as well as a completely-rewritten autocomplete system for the location bar. The new version shipped in only six languages, but our hard-working localization teams are readying three more languages for Camino 2.1.1.
2. In addition to Camino 2.1, we released three security updates for Camino 2.0 and three milestones on the road to 2.1, for a total of seven releases shipped in 2011.
3. At the end of March, Mozilla announced the end of Gecko embedding, and as a result, we issued a blog post on the future of Camino.
4. We found ourselves very fortunate that there was no tinderbox excitement in 2011; the most exciting change in that area of the project was when I finally turned off Camino 2.0.x builds in December.
5. While there were no large website projects (or problems!) in 2011, we did do a significant update of the site content, both text and images, to coincide with the Camino 2.1 release. In addition, Samuel Sidler started a special project that he has yet to complete.
6. Once again the composition of our development team shifted as life and job changes impacted the free time of our all-volunteer team. In particular, this resulted in a virtual hiatus in the spring as many of these changes coincided. Thus, for most of 2011, only Stuart Morgan and I were actively working on Camino code—and not always regularly even then. Philippe Wittenbergh continued to help out with graphics and design, as well as QA and user support, where Chris Lawson pitched in as well. I enjoyed spending more time working on Camino code but sadly found myself stretched thin due to my older build and release, website and documentation, and support responsibilities.

Coming so close on the heels of Camino 2.1 and after such an exhausting year, this summary feels a little bit like it’s just a quick rehash of my Camino 2.1 release post—perhaps, for once, this annual post is an abbreviated one. Still, it provides an overview of the year’s major events in the world that surrounds our favorite web browser. As always, I want to thank the entire Camino community—developers, testers, localizers, users, and friends—for all of the help and support in 2011; Camino could not have made it this far without your contributions.

2012 is the year in which Camino turns 10, which is both exciting and bittersweet. I remain hopeful for the future over the coming year and look forward to diving back in to Camino work as the holidays wind down (and, in particular, shipping Camino 2.1.1 soon). If you want to help build the future of Camino, please do join our development discussion list—perhaps one of your New Year’s resolutions is to help develop your favorite browser? So here’s to 2012; together, let’s make it a great year for Camino!

Scripting is the new literacy. A hundred years ago, the dividing line was the ability to read and write. Today, it’s between people who can code simple things, and those who can’t. It’s so liberating to have an idea and be able to bend the computer to your will. I’ve found that of the most rewarding experiences in life is to create something that provides a useful function for other people. There’s an intrinsic goodness in it, like how I imagine what a true craftsman would put into a chair, table or door. You build it for the ages.

While I disagree strongly with the beginning of the quoted passage, and somewhat with the end, the middle rings true with me. I enjoy being able to write simple things to help me accomplish a task, and sometimes those pieces of “software” are even useful to others. Like many before me, I started finding my way around the Camino codebase and attempting to pick up Objective-C and Cocoa in part to fix things that bugged me, to bend Camino to my will (to paraphrase Matt).¹ And although I’ve gotten great satisfaction out of fixing some bugs that have bothered me or have required some persistent debugging to fix, the most rewarding fixes—then and now—have been ones that have helped out others. It certainly isn’t saving the world, but if some code I write solves a problem someone else is having and makes their life just a little bit better or easier, it’s time well-spent.

Wishing you all the best this holiday season.

¹ The other part of my reason for attempting to pick up coding was to provide more manpower and help keep development moving—something with which nearly all small open-source projects could use a hand. ↩

The road to 2.1 has been longer—and I think harder—than any of the prior release journeys I’ve been a part of, dating back to the long-awaited 1.0. While work on 2.1 began even before 2.0 was done (Dan Weber’s Summer of Code autocomplete work was already on “the trunk” when 2.0 was released), things really got going in early 2010, when Christopher Henderson banished Mork history and nearly single-handedly got Camino building and running on both Gecko 1.9.1 and Gecko 1.9.2. Unfortunately, the devil was in the details, and we (mostly heroic hacker Stuart Morgan) spent an inordinate amount of time tracking regressions caused by Gecko changes that ignored or didn’t work properly in embedding clients like Camino.

Still, we pushed onward, joined for a time by Chris Peterson (who made a significant contribution after Christopher Henderson had to cut back his involvement), and with a brief return visit from Camino 2 feature hero Sean Murphy alongside contributions from Camino stalwarts Ilya Sherman, Chris Lawson, and Philippe Wittenbergh. In all, we fixed approximately 400 “bugs” (problems or new features) on the road to Camino 2.1, with 15 different people contributing (for the very first time, and I hope the last, I topped the list, with 195 fixes—although about 50 of those are website changes¹). Still, it was a much longer process than we had hoped or wanted, but as I noted with the previous major release, Camino 2.1 is still a major improvement over Camino 2 and a triumph for an all-volunteer, all-free-time development team in today’s world of corporate-produced browsers.

Sadly, due to increased demands on the time of our hard-working localization teams, Camino 2.1 is going to launch with a record-low number of languages—just six—though three more will be be available again in future updates. If your language is one of those missing, please stop by the caminol10n mailing list and see how you can help bring these localizations back. (Localizing doesn’t require much specialized computer/software knowledge, and the updates required for languages that previously shipped in Camino 2 are not as comprehensive as with past releases; you and a friend can bring Camino to thousands of users in your language!)

For the first time ever, I believe, both Sam and I managed to get a full night’s sleep before a major release! The website was all ready beforehand, although we have few tweaks and changes that were safe to postpone until after the release.

The road to 2.1 has been, for me, a grueling journey, as if I were sprinting a marathon and, at times, simultaneously herding cats. Between development team changes, monkeywrench bugs, and a trying spring, I am exhausted. I am, however, incredibly grateful to everyone who has contributed to this fine new release—developers, reviewers, designers and artists, localizers, testers and bug reporters, and the rag-tag “support staff” working in Bugzilla and on the forum to address problems—and to getting Camino 2.1 shipped to our users. It has been an honor and a privilege.

I may manage to take a short break that’s actually a real break and then jump back into fixing bugs for Camino 2.1.1. Beyond that, it’s still hard to say. If you have any development experience and would like to contribute those skills and your time, please join us on our development discussion list to help us chart the future of Camino.

In the meantime, however, enjoy Camino 2.1; we hope you find it familiar but better, like an old friend fresh from new experiences.

¹ At least another handful of my remaining bugs were other non-code-related changes, and by lines of code or significance of patches, though, Stuart is still going to come out ahead. ↩

Farewell, Steve, and thanks for changing this world while you were in it. My thoughts are with your family and friends tonight.

Ave et vale…

…And thanks for all the Macs.

Sunday night Stuart and I landed the last two bugs we’d been waiting on for Camino 2.1 Beta 1, so our final preview is now code complete. There is still some release note- and website-related work to be done before we can build and ship Beta 1, but we’re close enough that you can start counting down the days!

In all of the cases we have successfully debugged so far, users have had corrupt or invalid fonts which have, in conjunction with the font handling changes in Mac OS X 10.6.7, caused Camino to crash. Luckily, there is a relatively simple series of steps you can take to restore stability to your OS and prevent Camino from crashing:

1. Validate your fonts using Font Book; remove or disable all fonts with errors or warnings, as well as any duplicate fonts.
2. Restart your Mac in Safe Mode to clear the OS font caches (which contain data for the corrupt or invalid and duplicate fonts you removed/disabled in step 1).
3. Restart your Mac normally, and Camino should no longer crash from these font-related crashes while browsing.

If Camino still crashes after removing corrupt, invalid, and duplicate fonts and restarting in Safe Mode, please post in the support forum so that everyone can help further debug your problem (and please include links to crash reports you’ve submitted for these crashes).

Special thanks to Philippe Wittenbergh for his always-expert memory of the steps necessary to resolve font cache corruption.

Lately I’ve come to understand the rationale behind those hat tricks; after digging through a bunch of code to understand it and be able to fix the bug you’re after, it makes sense to go ahead and tackle other bugs in the same code. So, recently, I’ve been channeling smfr, fixing sets of bugs in our save code, in our HTML bookmarks export code, and in our pasteboard and local-file-decoding code, among others. They’re not smfr-level fixes, but they are fixes that have removed many longstanding bugs (and, in the case of HTML bookmarks export, improved the ability of that export to serve as a backup without significant data loss). And, in the end, they keep moving Camino forward, and that’s what really matters.

Beginning with yesterday’s (January 27^th) nightlies, the sourcestamp file ($product-$version-$language-$platform.txt, e.g. firefox-4.0b11pre.en-US.mac.txt) produced alongside every build changed formats.

History

Since its introduction in February of last year, the sourcestamp file had been a single line with two space-delimited values, the build ID and the repository revision/changeset (in theory always the revision of the platform repository, e.g. mozilla-central, but in practice instead using the comm-* revision in the comm-* repositories due to differences in the way the two repositories were set up):

20110126030333 e0fc18b3bc41

Changes

Unfortunately, this old format was only fully useful for Firefox, since all other mozilla.org products are built from multiple repositories and would need to list two (or more) revisions/changesets. So in bug 549958 I changed the sourcestamp file format to be a multi-line file, where the first two lines are always the build ID and the platform changeset URL (regardless of which repository an app is built from):

20110127030333
http://hg.mozilla.org/mozilla-central/rev/b5314bc1a926

At the time I wrote the patch, the only known consumer of the sourcestamp file was Socorro. With the recent migration, Socorro’s code to handle both sourcestamp file formats was deployed, so we could finally change the file format; this happened Wednesday night.

There have been a couple of unexpected breakages as a result, for which I apologize. If you have a tool that consumes the sourcestamp file (or code that uses the MOZ_SOURCE_STAMP variable that was defined and exported by mozilla-central), please check to make sure it can handle the new format in addition to the old one and the output is still as expected.

mozilla-1.9.2 and mozilla-1.9.1

This change is currently only in place on mozilla-central; however, I intend to try to land this change on the branches for the the release cycle following (the soon-to-be-released) Gecko 1.9.2.14/1.9.1.16. Doing so will ensure that all branches are in sync and that tools that only work with “current builds” will not have to maintain code to handle both formats indefinitely; you can follow bug 549958 to keep abreast of branch landings.

New Goodies for Multi-Repository Apps

For applications that use multiple repositories (mozilla-central and an app repository, for instance), it’s now possible to add the app repository’s revision (or app repositories’ revisions) to the sourcestamp file.

If you’re already calculating your application’s source stamp and repository (for instance, for inclusion in application.ini) and exporting those variables, you need only make one small change to your app’s installer/Makefile.in:

# Add our own changeset information to the MOZ_SOURCESTAMP_FILE
make-sourcestamp-file::
	@echo "$(APP_SOURCE_REPO)/rev/$(APP_SOURCE_STAMP)" >> $(MOZ_SOURCESTAMP_FILE)

If your application isn’t currently calculating these values, you can copy the MOZ_SOURCE_STAMP and MOZ_SOURCE_REPO rules from toolkit/mozapps/installer/package-name.mk, change the variable names, and substitute the appropriate directory for $(MOZILLA_DIR) in order to calculate the correct values (placing the rules in an appropriate Makefile and exporting the variables as required).

Were Thunderbird, for example, to add this information, its sourcestamp file would look like this:

20110128045924
http://hg.mozilla.org/mozilla-central/rev/a84260b56b08
http://hg.mozilla.org/comm-central/rev/0f313f7b192e

With these changes, your QA team will be able to regression-hunt through old builds and easily know the revisions of all repositories in question before they even download the build!

Wevah stopped by #camino on Sunday to help Sam fix a server migration-related website bug we’d just discovered. Before the day was out, not only had Wevah fixed that site bug (Regex Jesus to the rescue!), but a second one as well.

Even better, he fixed a three-plus-year-old “blocker” Colloquy bug 10 minutes after I mentioned the bug to him (it’s almost as if he scares bugs into fixing themselves).

The best part of it all is that Wevah’s awesomeness rubs off on everyone around him; after Wevah finished his bug-fixing spree, I looked again at a bug that had been stumping me for some time (Wevah had actually given me the hint that allowed me to fix said bug’s predecessor) and was then able to re-arrange some code and get things working.

Fixing bugs is never more fun than when Wevah is around; everyone should be so lucky to work with Wevah on a project sometime.

And that, my friends, is why Wevah is awesome!