Firefox 2.0.0.14 by the (wall-clock) numbers

Mozilla released Firefox2.0.0.14 on Wednesday 16-apr-2008, at 3:05pm PST. From “Dev says go” to “release is now available to public” was just over 12 days (12d 3h 20m) wall-clock time, of which Build&Release took just over 3.5 days (3d 14h 35m).

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

Notes:

1) Our blow-by-blow scribbles are public, so the curious can read about it, warts and all, here. Those Build Notes also link to our tracking bug#426307.

2) While this was a firedrill release, and it went quite smoothly, it still some non-technical delays making the wall-clock numbers longer then usual.

  • The code fix was landed mid-day Friday, and builds started lunchtime Friday. However, the Build and QA groups explicitly did not work the weekend, after a recent series of working weekends, adding an artificial delay waiting for manual announcements and signing.
  • We decided to extend the beta period from 14apr until 16apr, to avoid possibly disrupting people’s online US tax submissions on 15apr.
  • Like before, we waited until morning to start pushing to mirrors, even though we got the formal “go” the night before. 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. We suspect that coordinating the mirror push like this reduced that likelihood just a bit, but it feels like we should verify that. We continue to count this waiting time as “Build&Release time”, even though we are all just waiting.

3) Mirror absorption took just over 3 hours to reach all values >= 65%, a higher then usual threshold.

take care

John.