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.

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.

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.