Firefox by the (wall-clock) numbers

Mozilla released Firefox2.0.0.13 on Tuesday 25-mar-2008, at 16:30pm PST. From “Dev says go” to “release is now available to public” was 15.25 days (15d 5h 55m) wall-clock time, of which Build&Release took just over 2.33 days (2d 8h 10m).

10:35 10mar: Dev says “go” for rc1
14:50 11mar: FF2.0.0.13 builds started
16:55 11mar: FF2.0.0.13 linux builds handed to QA
19:00 11mar: FF2.0.0.13 mac builds handed to QA
07:10 12mar: FF2.0.0.13 signed-win32 builds handed to QA
14:40 12mar: FF2.0.0.13 update snippets available on betatest update channel
11:30 18mar: Dev & QA says “go” for Beta
12:25 18mar: update snippets on beta update channel
09:10 25mar: Dev & QA says “go” for Release; Build already completed final signing, bouncer entries
10:25 25mar: mirror replication started
11:20 25mar: mirror absorption good for testing to start on releasetest channel
14:20 25mar: QA completes testing releasetest.
15:00 25mar: website changes finalized and visible. Build given “go” to make updates snippets live.
16:00 25mar: update snippets available on live update channel
16:30 25mar: release announced


1) This was Ben Hearsum’s first time doing a release. He works in the Release group, and he’s smart, but he’s never done a release for Mozilla. Ever. The fact that he jumped into doing this release with absolutely no advance notice, and was able to use our existing automation without needing to ask any questions at all says lots about both Ben and how things are improving.

2) From Build’s point of view, this was a fast release. We took 2 days 8 hours, which is one of our fastest releases ever. Note: between the “Dev says go to build” and “build started” was a delay of 1 day 4 hours where Build did nothing. This delay was because we were busy with 3.0beta4 and also trying to balance out some other workloads across the group. I counted this delay as part of our 2days 8 hours, but I have to point out that if we had been ready, our total time for FF2.0.0.13 would actually been halved; we would have only needed a totally screaming fast 1day 4hours.

3) For better or worse, we are putting all our blow-by-blow scribbles public, so the curious can read about it, warts and all, here. Those Build Notes also link to our tracking bug#422122.

4) Like before, we waited until morning to start pushing to mirrors. This was done so mirror absorption completed as QA were arriving in the office to start testing update channels. We did this because we wanted to reduce the time files were on the mirrors untested; in the past, overly excited people have post the locations of the files as “released” on public forums, even though they are not finished the last of the sanity checks. Coordinating the mirror push like this reduced that likelihood just a bit.

5) Mirror absorption took 1 hour to reach all values >= 50%, slightly faster and slightly lower then our usual threshold.

take care


One thought on “Firefox by the (wall-clock) numbers