In a sure sign that summer is about upon us, the honeysuckle is out all over the yard, and it smells heavenly. It even overpowers the smell of lawn-mowing, no easy task, I assure you.

As I was mowing the lawn, I couldn’t help but wonder, though: how do you describe the smell of honeysuckle? Were you to describe something to me and say it smelled like honeysuckle, I would comprehend your meaning, but I can’t think of any primitives or comparisons I’d use to describe the smell to someone unfamiliar with honeysuckle.

How do you describe that smell?

Initially things were great; WordPress updates appeared in Fantastico within about a week of release (given that the Fantastico developers needed to QA any changes a WordPress upgrade might need in their software and that hosting providers should QA any Fantastico upgrade on their servers before deploying, six or eight days seemed both relatively fast and reasonable). As time went on, however, new versions of WordPress and their security upgrades started taking longer and longer to appear in Fantastico (the last WordPress upgrade I did with Fantastico, to 2.3.3, took almost 40 days to appear in Fantastico, and both WordPress 2.5 and now 2.5.1 have been released without Fantastico upgrades appearing yet), and exasperated users complained in hosting providers’ forums, and exasperated providers complained in the Fantastico forums. Fantastico was no longer so fantastic.

Seeing the writing on the wall, I had been looking for solutions that were elegant, efficient, and easy. WordPress recommended putting your WordPress install in a Subversion repository (not easy), and later the WordPress Automatic Update Plugin appeared (not efficient), but, frankly, I wanted something tested and supported, in case something happened (and if I was going to have to mess around with things, I’d rather just use patch like phpBB used to support; patch and I are friends). Not too long ago, my host announced support for SimpleScripts, which promised more up-to-date releases and updates. The only drawback was I’d have to do some sort of “migration” to get افكار و احلام into the SimpleScripts system, either migrate the installation itself or migrate the data. Yay, more deferred maintenance.

Finally, this weekend, I set aside some time to perform all of these delayed changes. I had been reading the threads about Fantastico→SimpleScripts WordPress migration in the BlueHost forum (as well as lots of other documentation) for the past few weeks, so I knew I needed to set aside a couple of hours in case anything went wrong. The steps were simple enough; they just required some quiet and time.

I ended up mostly following these instructions (phpMyAdmin database backup instructions I followed are here) to get my existing WordPress 2.3.3 install into SimpleScripts, though I changed steps 5 and 6, which eliminated steps 7-10:

• Use Coda (Have I mentioned how much I love Coda? No? OK, I will soon, then.) to copy afkar/ to afkar_copy/. This took more time than just renaming the existing directory, but it also meant that I didn’t have to re-upload themes, plug-ins, and other stuff in wp-content when I was done, but I still had a pristine copy to revert to in case of problems.
• Instead of having SimpleScripts create a new database, I had it update the existing database (I had several backups, from cPanel, WordPress itself, and the SQL backup from phpMyAdmin) using the information from my wp-config.php file. This is more “dangerous” and probably more trouble if something were to go wrong, but fewer steps if things went well (which they did for me).

Of course, I also had to fix the DB_CHARSET in wp-config.php again after the migration.

I then made another series of backups (though SimpleScripts will also create and restore backups when/after upgrading), disabled my installed plug-ins, and upgraded from 2.3.3 to 2.5.1. “Shiny,” as they say. I backed up again for good measure and then upgraded all of the WordPress plug-ins I had installed (a couple didn’t show updates in the WordPress UI, but I visited their sites and found there were updates available anyway).

Having now completed almost all deferred maintenance, and without any problems, I decided it was high time to fix that pesky DB_CHARSET issue once and for all. After all, nearly a year had passed since WordPress 2.2, and there were finally WordPress “instructions” on how to fix their poor database encoding choice/upgrade bug—except the instructions were just a general overview, suitable for folks familiar with databases, but not for average users. Fortunately, a user had written a plug-in to do the job for you. I had been reading about it for a while, it had been updated a couple of times, response had generally been positive (I had seen a couple of comments indicating it hadn’t worked at all, but also this recent one indicating success even with 2.5), and I had fresh database backups and some time left!

The plug-in dutifully warns that it’s only been tested against WordPress 2.2, but after I acknowledged that I was taking my database’s life into my own hands, it offered to proceed anyway. After the converter finished its work, the only thing I had to do was set the DB_CHARSET back to utf8 in wp-config.php; I hope this is the last time I will ever have to change that variable!

The end result of an hour or so of “work” is a fully up-to-date WordPress installation, a sane database, no more deferred maintenance sitting around, and, hopefully, quick upgrades to newer versions of WordPress in the future. SimpleScripts seems simple, efficient, elegant, and it even addresses my other complaint about Fantastico), so I’m hopeful it will remain simple for much longer than Fantastico remained fantastic. Thanks, as always, to the great folks on the internet whose commentary and instructions facilitated my afternoon of upgrades.

Let me assure everyone that both the Camino development team and the Camino localizers were unhappy about this, too. However, all Camino work—development and localization—is done by volunteers, and schedules of volunteers do not always line up. This was exactly the case with our Spanish localization; it wasn’t going to be ready in time for us to ship Camino 1.6 as planned last week. We knew this in advance, and while we always hate to ship a Camino release without a language included in the previous version, we needed to ship 1.6 and we did have 10 other languages ready.

As of this evening, the Spanish translation is nearly complete, and the first review indicates there is not much more work to be done. I can’t promise you a new Camino 1.6 Multilingual build that includes Spanish by the end of the week, but it is safe to say that you’ll see Spanish in the Multilingual build very soon.

As always, if you’re concerned about the status of the translation of Camino in your language, please stop by the caminol10n project and see how you can help. You don’t need to have many computer/software skills, and some languages just need reviewer/proofreaders—the only skill required for that task is your language and the ability to use Camino!

We thank all of our Spanish-speaking users for their patience, and we do hope to deliver the Spanish localization very soon.

Interestingly, we did receive quite a few applications about improving OOXML support, while we got zero OpenDocument related proposals. Apparently the support for the OpenDocument ISO standard isn’t strong enough in the F/OSS community to actually make an effort to improve support for it. Even when paid. Food for thought.

Both sad and disturbing for advocates of truly free and open standards for document formats (of which I am one).

The road to Camino 1.6 began in May 2007, when Mark Mentovai cut the CAMINO_1_5_BRANCH for Camino 1.5 security releases and the first fixes for 1.6 landed on the MOZILLA_1_8_BRANCH even as we finished work on Camino 1.5. Over the course of nearly a year thereafter, Camino contributors fixed nearly 400 “bugs” (problems or new features), and 18 different people contributed patches for this release (with Stuart Morgan leading at 153 fixes). Big thanks to the half of that list of patch contributors who aren’t regular Camino developers; every little (or big, like multiple accounts support for the Keychain) fix helps make Camino a better browser.

If you remember back to my Camino 1.5 wrap-up, the number of bugs fixed in Camino 1.6 is lower, but this was designed to be a smaller release. The fact that the number is not that much lower shows that Camino 1.6 ended up being a bigger release than you might otherwise expect from a 0.1 increase in version number (we played the late-stage version number “game” before, but we opted not to do it again). No matter which way you look at it, Camino 1.6 is another major accomplishment for our all-volunteer, all-free-time development team.

Thanks to the efforts of our fabulous localization teams, Camino 1.6 is available in 10 different localizations in addition to US English, with Spanish expected to join that list soon. Sadly, we had a few languages that shipped in Camino 1.5 disappear on us, so if your language is missing, please stop by the caminol10n mailing list and see how you can help bring these localizations back. (The work doesn’t require much specialized computer/software knowledge, and some of the existing localizers have volunteered to mentor new or revived localizations. Last year new contributors successfully revived the Norwegian localization, which was in Camino 0.8 but disappeared from Camino 1.0; you and a friend can bring Camino to thousands of users in your language!)

Again this year I went to bed last night while our fearless webmaster Samuel Sidler stayed up to put the finishing touches on the home page, the Features page, and dozens of other bits around the website. Aside from some afternoon connection issues, the website update felt like it went more smoothly than 1.0 or 1.5 did (I guess it helps when you’re not completely re-designing a site or adding tons of new support content ). Special thanks to Stuart for his last-minute debugging and testing during today’s release.

What’s next? Those of us who have been working on the website and other release details are going to take a rest for a while. Most of the development team, which had only a few things left for 1.6 after last month’s Beta 4, have been slowly ramping up to work on Camino 2.0. There’s not much visibly new over Camino 1.6 in the nightly builds yet (lots of Gecko changes, and Tabsposé is there but hidden), but there are some great new features already in progress that you should be seeing in the coming weeks.

In the meantime, enjoy Camino 1.6 and let us know what you think!

As I read the posts from his former co-workers and friends in the Mac community, I began to wonder…had it really been nearly 15 years since I’d started following the Mac web? I remember when MacCentral switched from publishing every-other-day to daily, I remember how MacCentral would always commemorate Remembrance Day (Stan was Canadian; it’s Armistice Day or Veterans Day to the rest of us), and I remember the tiny little icons that MacCentral used in the early days to help differentiate the story type.

In fact, it’s those little icons (part of a bygone era on the web, and perhaps happily so) that are the reason I’m writing this at all. Shortly after a redesign in which they disappeared, I sent a little note to MacCentral’s feedback address politely lamenting their demise. Much to my surprise, I later received a response from none other than Stan Flack, Publisher of MacCentral, himself. The email is lost to the depths of time, but I recall him thanking me for the feedback, explaining why the icons went away, adding that he missed them a bit, too, and he’d look to see if there were other ways to use them (or something to that effect). The top guy responding to inconsequential feedback himself. I can’t claim to have known him, but from reading what others have written, that was the kind of person Stan Flack was.

As for those little icons, maybe it’s just my mind, but I’ve always thought that MacCentral’s post-redesign site logo and, later, its site icon () were reminiscent of those little globe-like icons that made reading only the stories I was interested in so easy. Those days seem so long ago and far away now….

And so, feeling older and with a sadness over the untimely passing of one the Mac web’s pioneers and enduring figures, I offer my happy memories of one of the greatest Mac news sites during the golden age of the Mac web, and of the man behind it, and I offer my condolences to the family and friends of Stan Flack.

Posts from some of Stan Flack’s friends and former co-workers:

• Jim Dalrymple
• Dennis Sellers (the comments section reads like a who’s who of the Mac web of the golden age)
• Peter Cohen
• Ted Landau

[Qalaat-Samaan:dev/trunk/mozilla] smokey% uname -a
Darwin Qalaat-Samaan.local 9.2.2 Darwin Kernel Version 9.2.2: Tue Mar 4 21:17:34 PST 2008; root:xnu-1228.4.31~1/RELEASE_I386 i386
[Qalaat-Samaan:dev/trunk/mozilla] smokey% history | awk ‘{a[$3]++ } END{for(i in a){print a[i] ” ” i}}’ | sort -rn | head
24 make
11 cvs
10 cd
8 open
6 history
5 edit
4 patch
3 diffscrape
2 touch
1 svn
1 ls
1 cp

Notes:

1. This is the sum for my six current active Terminal tabs from the tail end of One License to Rule Them All (Phase 2) on (I had to quit Terminal once I had the fix mostly complete because of some sort of corrupted environment setting). For the morbidly curious, there are another 11 open tabs for other branches and trees I haven’t built since restarting Terminal.
2. If there were some way to track Coda saves and MediaWiki edits…that would tell the tale!
3. Pretty much every launch of Camino to test something goes through Troubleshoot Camino these days, so all of those would-have-been open path/to/one/or/another/Camino.app commands are also missing.
4. Thanks to bz for tcsh variant; otherwise I wouldn’t have been able to play along and take this needed break.

For a long time bug 368091 sat unloved, with the neglect punctuated by brief flurries of activity which generally ended with exasperation and stalemate over seemingly mutually incompatible requirements. In the meantime the two copies of license.html grew to three, and every change to about:license had to be made either three or six times across mildly-forked copies of the file. This was no fun for anyone involved, including branch drivers approving changes for licensing compliance. Finally, after Stefan Hermes filed a bug last month about bad redirects on mozilla.org (and indirectly about bad URLs in SeaMonkey following its switch to Toolkit), I decided to post an interim patch for 368091 just to get the discussion moving again. Several weekends (and two additional patches for 368091 and one for Thunderbird), we’re down to only two copies of license.html on the trunk, and the Toolkit copy is now suitable for all mozilla.org applications. Phase 2 is complete!

For the curious, toolkit/content/license.html is now pre-processed before being packed into toolkit.jar, which ensures the copy of the license in toolkit.jar is devoid of application- or organization-specific EULA blocks. Firefox now takes toolkit/content/license.html, pre-processes it to include the Mozilla Corporation EULA block, stuffs that file in browser.jar, and sets up a chrome override so that about:license’s chrome URL (chrome://global/content/license.html) is overridden with the chrome URL for the Firefox-specific version. Thunderbird currently strips out the “about:license” fragments of all of the anchors in toolkit/content/license.html and ships a stand-alone file instead of shipping a stand-alone forked copy of license.html; after bug 428144, Thunderbird will also post-process in its EULA block. If you’re building a browser-type application, you can use the Firefox model to build your own license file; if you’re building a non-browser application, the Thunderbird model (most of Phil Ringnalda’s original “ship a stand-alone file” work in bug 339117 plus my patches from bug 427316 and bug 428144) should work well for you.

When I started filing these bugs back in June of 2006, I never intended that “one license to rule them all” would turn into what appears to be an obsession (at that point, I certainly didn’t expect I would fix any of the bugs along the way, let alone most of them). For over a year bug 368091 has been my #2 tab—perhaps that should have clued me in to the borderline obsession—and I’m delighted that I can finally close that tab. We’re not quite done with the quest to drive the number of license files on the trunk to one—XPFE (and thus Camino) still has a copy, but its days are numbered once I’m done with Camino 1.6 release work—and there are a couple of other follow-ups to finish, but we’ve completed the hard part of the trek.

This has been an interesting journey for me, and I extend thanks to everyone who helped out along the way—Gerv Markham and Frank Hecker at the Foundation, Robert Kaiser, Chris Thomas, and Stefan Hermes from SeaMonkey, Phil Ringnalda from Thunderbird (who, among other things, kept reminding us that any solution had to work for non-browser apps), Reed Loden on the www.mozilla.org side of things, Benjamin Smedberg for finally driving me to the correct solution, code review, and the SunOS tinderboxen bustage fix, and Samuel Sidler for getting things rolling (perhaps I should be cursing him instead? ).

Stay tuned for Phase 3, coming in a few weeks, and then our long international nightmare will be over.

• Since the last update two weeks ago, we’ve released two new betas. As usual, Stuart Morgan was chasing down the last bug fixes, Mark Mentovai did the build-wrangling, and I handled pushing all the changes to the website and to software update.
• In addition to chasing down the last few beta blockers, Stuart has also been alternating between working on the few remaining code bugs for 1.6, starting to clean up regressions on the trunk caused by Core changes, triaging the 2.0 bug list, and doing other fun code cleanup. He also snuck in a patch to support a couple of multi-touch gestures produced by Apple’s new MacBook Air and MacBook Pro trackpads.
• Chris Lawson, working with Philippe Wittenbergh’s river of error reports, got Camino trunk building again with the 10.5 SDK (we last verified 10.5 SDK compatibility before we made compiler warnings fatal, so the problems were only warnings about deprecated functions).
• Our fearless leader, Mike Pinkerton, wrote a brief note in honor of Mozilla.org’s 10^th anniversary. For more of his remembrances of the decade, you can read (or listen to) his interview with the Mozilla Digital Memory Bank or watch his Google TechTalk.
• Sean Murphy finished his work to prevent Camino from completely overwriting corrupt WebSearchEngines.plist files and continued his investigation of a new feature we’re tentatively planning for Camino 2.0.
• In addition to my work on the two betas, I worked on finishing up the set of files that our localization teams will need to translate for the ✈ release (Mark had the final word on the text, as always). In between working on updating the website so that it will be ready for the release of 1.6, I’ve written a few small patches to Gecko’s Mac font defaults. I also spent some time this weekend working on the “one license to rule them all” problem and made Thunderbird generate its license.html file from the shared Toolkit file, reducing the number of copies of the license file from three to two. Once we make the shared Toolkit file sufficiently generic, we can reduce that number down to one.

As the pilots say, we’re going through our pre-flight checklist right now, and we expect ✈ to be cleared for takeoff in about a week, depending on the schedule for the next Gecko release. In the meantime, please let us know if you find any problems in Camino 1.6 Beta 4.

I don’t remember much about the Camino 1.0 betas (it seems like ages ago!), so they were probably mostly “major crash”-free. Many of you will recall, though, that Camino 1.5’s sole beta was particularly plagued by a random crash, and while we did urge everyone to move to a new build, we didn’t release a new beta (which, in hindsight, we should have done). More recently, Camino 1.6 Beta 1 had not even officially been released when we replaced it with Beta 2 due to a just-fixed Core crash. Thanks to software update, it’s much easier to release a new version and ensure everyone gets notified and upgraded in a timely fashion, though we don’t want to do so too often and induce “update fatigue” among our users.

Yesterday a user reported a crash when clicking on a <select> during pageload, and although I couldn’t reproduce the crash and hadn’t seen it in my testing and use of Beta 3, his crash log was plausible. However, Stuart Morgan was finally able to reproduce the crash on one of his Macs, and he worked up a fix right away. When early reports indicated that a large number of users could be hitting this crash, we decided earlier today that we should release a Beta 4 to fix that crash (and another, much less common, crash that Stuart had also fixed on Wednesday). As far as we can tell, the Beta 4 release has gone a bit better (no crashes in Talkback yet!)—knock on wood—and it seems that I managed not to flub any of the website changes this time around, too.

Thanks go again to Stuart Morgan for the bug-fixing, Mark Mentovai for the build-wrangling, and Mozilla Corp’s Nick Thomas for getting us in Bouncer right away.

Special thanks to everyone who reported this crash, either in Bugzilla, the forum, or in via Talkback (for those using PPC Macs), and we apologize to everyone for the inconvenience. (And I hope this is the last release I write about before Camino 1.6 ✈ itself!)