Japan: two weeks later

Still having a hard time grasping the scale of the earthquake in Japan. Most of the news in California is focused on the nuclear power plants at Fukushima, but the following struck me about the earthquake:

Its great to see Wikipedia and GoogleCrisisResponse spreading timely information, which is really important in situations like this.

This is two weeks later.

We get earthquakes here too, which raises the question: if an earthquake happened here in the bay area, could you be fully self-sufficient for at least 72hours? San Francisco Dept of Emergency Management has setup http://72hours.org to help people prepare.

UPDATED: added today’s story about the dog. Searching building wreckage is dangerous, more so when its floating at sea, so I’ve lots of respect for the people continuing to do this day after day. joduinn 02apr2011.

Where does time go when you build?

Following on from this blogpost about how much time is spent in Makefiles, pcwalton sent me a link to his blog. He has a great breakdown of mac osx builds, showing where all those minutes go for each mac osx build.

We spend ~55% of the time compiling (“g++-4.2”, “gcc-4.2”, “gcc”), but whats in the other 45% – and why?? Some investigation work ahead of us. Thanks pcwalton for doing all this work – data like this really helps figure out where to focus attention first.

Branch mechanics for Firefox4.0, Fennec4.0

To cater for some last minute code changes, we had to make last minute changes to our branching and automation plans for Firefox4.0, Fennec4.0.

For mechanical branching details like this, a diagram of the revised plan is worth at least a thousand words – hopefully this photo of the whiteboard near my desk makes sense:

To set context, existing repos/branches are red lines and planned FirefoxNext/FennecNext repos/branches are green lines. Within that context,

FF4.0 (black lines):
* will build using bits from mozilla-2.0 and l10n-mozilla-2.0
* to avoid having developers and localizers land patches twice, for FF4.0rc1, RelEng did the following at “go to build”:
** copied over from l10n-central to http://hg.mozilla.org/releases/l10n-mozilla-2.0
** copied over from mozilla-central to http://hg.mozilla.org/releases/mozilla-2.0
* now that fennec-specific changes have landed on mozilla-central, RelEng will no longer copy everything over from mozilla-central to mozilla-2.0. Instead, developers with any last-minute fixes for Firefox4.0 will have to double land on mozilla-central and mozilla-2.0 after approval, just like they currently do for mozilla-1.9.2, mozilla-1.9.1.
* after the last 4.0RC, these same repos will be used for FF4.0.1, FF4.0.2…

Fennec4.0 (blue lines):
* will build using bits from mozilla-2.1, mobile-2.0, l10n-mozilla-2.0 (previous betas were built from mozilla-central, mobile-browser, l10n-central)
* Fennec4.0RC1 cannot build from mozilla-2.0, because of last minute Fennec fixes that are too risky for Firefox4.0. Instead Fennec4.0rc1 will be built from newly created mozilla-2.1.
* Fennec4.0RC1 was planning to build from mobile-browser, but now instead will build from releases/mobile-2.0. These changes ensure that all infrastructure is lined up in case we need to do a fast Fennec4.0.1 release immediately after Fennec4.0.
* to avoid having developers and localizers land patches twice, for Fennec4.0rc1, RelEng will do the following at “go to build”:
** copy over from mobile-browser to http://hg.mozilla.org/releases/mobile-2.0
** copy over from l10n-central to http://hg.mozilla.org/releases/l10n-mozilla-2.0
** RelEng will repeat this until Fennec4.0rcN is signed off and released.
* after the last 4.0RC, these same repos will be used for Fennec4.0.1, Fennec4.0.2…

There’s a lot going on here, so hope all this makes sense! Of course, questions/comments very very welcome.

ps: Debate continues on consolidating mobile-browser into mozilla-central immediately after Fennec4.0 ships, and also about the larger faster-cadence of feature releases. We can revisit those topics later, but I’m explicitly ignoring both of these topics here, because I’m focused on what we need to do in order to *ship* Firefox4.0 and Fennec4.0 in the first place. Nothing here blocks those discussions, and its important to be able to release, and also have ability to ship immediately security fixes.

pps: for the curious, until recently, here’s what we were *expecting* to do for the Firefox4.0, Fennec4.0 releases,

and here’s the other option we considered – not as organized, but fewer last minute infrastructure changes and would also have worked to a certain extent.

“Go to build” Firefox 4.0rc1

We finally hit zero blockers, and stayed there, long enough that Beltzner felt it was safe to start building FF4.0rc1. So, today, at 12:09PST, beltzner sent the “go to build” email, and I took this picture.

At this point, some of the builds are already handed to QA, and we’ll have the rest to QA by first thing in the (PST) morning. You can feel the excitement in corridors and in irc channels.

Of course, this close to the finish line, it’s easy to get tempted to rush things, to take a shortcut to do things quickly – but that would only invite problems. Instead, we’re doing what we’ve done for every release – calmly, quietly, confidently, following a process that we’ve been refining and testing with every alpha, beta and security-release leading up to today.

(Oh, by the way, today we’re also calmly doing a chemspill Firefox 3.6.15 at the same time!)

This poster is just perfectly appropriate.

GODDZLA in the Mission

Walked past this Nissan GT-R parked on the side of the street in the Mission district of San Francisco. Spent several minutes walking around it, admiring. The license plate was a nice touch – wonder if the owner is involved with Mozilla? All the jokes about “a monster from Japan” are appropriate for this beast when you realize this 3.8L V6 Twin-turbo produces 485HP!