(Its been a while since my last “by the wall-clock numbers” post. After last week’s CanSecWest, I thought people might be interested in how much Mozilla’s pipeline for delivering code to users continues to improve. This was even noted by the pwn2own contest sponsors during the CanSecWest conference! ).

Firefox 19.0.2 was released on Thursday 07-mar-2013, at 16:40PST. From “go to build” to “release is now available to public” was 16h 26m wall-clock time, of which, the Release Engineering portion was 11h 27m. The wall clock times were:

00:21 07mar: ReleaseCoordinators say “go” for FF19.0.2
02:14 07mar: FF19.0.2 builds started
04:06 07mar: FF19.0.2 android signed multi-locale builds handed to QA
07:07 07mar: FF19.0.2 linux builds handed to QA
08:03 07mar: FF19.0.2 mac builds handed to QA
11:40 07mar: FF19.0.2 signed-win32 builds handed to QA
11:58 07mar: FF19.0.2 update snippets available on test update channel
13:05 07mar: ReleaseCoordinators say “go for release”; “ok to start mirror absorption”
13:11 07mar: ReleaseCoordinators say “go for push to Google play store”
13:29 07mar: FF19.0.2 android pushed to Google play store
13:55 07mar: mirror absorption started
14:00 07mar: mirror absorption good enough for testing
14:31 07mar: QA signoff on updates on test channel
15:26 07mar: ReleaseCoordinators say “go” to make updates snippets live.
15:40 07mar: update snippets available on live update channel
15:54 07mar: QA signoff on updates on live release channel
16:40 07mar: release announced; all done.

In addition to FF19.0.2, I note that we also had to ship FF17.0.4esr, FF20.0b4, Thunderbird 17.0.4, Thunderbird 17.0.4esr, Thunderbird 20.0b1 (build2) in the same super-fast way. Obviously, we don’t want to ship this number of products, this quickly, all the time, but its nice to know that we can if we have to. Really, really, nice. And yes, we quietly continue work to make this delivery pipeline even more efficient! 🙂

Notes:

1) I continue to measure the time between “dev says go” to “release is available”. Explicitly I do *not* measure from “fix is reported” to “release is available”, because I don’t want to put any further time pressure on a developer trying to fix a problem under pressure. It feels much better to me to work a little longer to get the fix right instead of adding even more time pressure looking for a quick fix, and then having to do another emergency release a few days later to fix the “quick fix”.

2) As usual, if you are curious for more details of the actual work done, you can follow along in tracking bug#848753, and various linked bugs.

Thank you to everyone in OpSec, RelEng, QA, IT and ReleaseCoordinators who make this all possible. It was a really busy few hours, but great to see everyone calmly pile, doing what they can to help out. The end result made us proud by our users.

John.