Buildbot job queues now visible from Tinderbox waterfall

The Tinderbox waterfall now has two new links at the top.

  • What jobs are ahead of you in the queue? If you landed a patch, but TPBL doesnt show it running yet, you should look here. This will show you what build/unittest/talos jobs, on what OS, are ahead of you in the queue, and give you an approximate idea of how long you’ll have to get to the top of the queue.
  • What jobs are running right now? Self-explanatory, and has more in-progress details than Tinderbox/TBPL while the job is still running.

For both of these, you can search by changeset, and you can sort on the different column headings. If people find this helpful, please send beer+chocolate to nthomas. πŸ™‚

Infrastructure load for *PART* August 2010

The pace towards Firefox 4.0 release is definitely picking up. FF4.0beta4 went out today. FF4.0beta5 is right behind it. The fast cadence of betas is one measure of how fast things are. Another way to measure how busy developers have been is by looking at #checkins :

  • 2,216: so far in August (as-of Sunday night 22nd, and we’ve still about 1/3 of the month to go!!)
  • 1,971: March 2010 (entire month – and our previous record)
  • 1,892: May 2010 (entire month)
  • 1,838: July 2010 (entire month)
      For comparison, we used to be able to handle ~1,000 checkins per month back in early 2009.

      If you are curious for all numbers going back to January 2009, see here:


Trying an experiment this year instead of the usual tent.

Some friends of mine had these last year, and they were great. Obviously, well insulated means warm at night, and cool in the day – all wonderful things at BurningMan. However, they also kept the dust down, and kept the light out, so you could actually get some sleep after the beginning of sunrise.

Lets see how this experiment goes. So far, we’ve got all the parts cut, and taped. We’ve even tried some initial test placements, but never yet actually put it all together yet. Just in case, we’re still bringing tents from last year – after all, “what could possibly go wrong”!?!


Stay tuned – I’ll let you know how it went.

Burning Man Emergency Services by the numbers

Every year at Burning Man, Emergency Services handles a range of incidents. Here’s an infograph showing incident data for the last 3 years, broken down by incident type.

The source data is freely published on, but I really like how they visualize the data. This layout is immediately familiar to burners and is visually intuitive – more incidents of a specific type == larger area for that type. Click on the thumbnail for a larger version, and spend a few minutes skimming details; it was interesting reading!

The authors (GOOD and Hyperakt) end with “Try not to get flown out by helicopter”!

Excellent advice! πŸ™‚

Burning Man InfoGraph

The countdown for Burning Man is well underway, so this infograph was a timely discovery.

Amidst all the other data, the comparison with other large events struck a chord with me. The complexity of logistics at Burning Man makes 50,000 people seem like a lot of people… until you see it alongside Glastonbury Festival (137,000), Woodstock Festival (500,000), the Hajj (1.6million) and Kumbh Mela (40million). Wikipedia (being Wikipedia!) has a page listing the largest gatherings in human history – a fascinating read!

Thanks to xmason for putting this infograph together, and to abillings for drawing this to my attention.

Infrastructure load for July 2010


July 2010 logged 1,838 pushes – very similar to last months 1,892 and almost our previous record of 1,971 in January. You can clearly see the drop in load between 3rd and 10th of July, caused by Mozilla Summit 2010. Oh, and yet again, TryServer was still the busiest branch of the entire infrastructure.

The numbers for this month are:

  • 1,838 code changes to our mercurial-based repos, which triggered 233,634 jobs:
  • 35,239 build jobs, or ~47 jobs per hour.
  • 111,603 unittest jobs, or ~150 jobs per hour.
  • 86,792 talos jobs, or ~117 talos jobs per hour.


  • There’s been lots of progress, but we are still double-running unittests for some OS; running unittest-on-builder and also unittest-on-tester. This continues while developers and QA work through the issues. Whenever unittest-on-test-machine is live and green, we disable unittest-on-builders to reduce wait times for builds.
  • The trend of “what time of day is busiest” changed again this month. Not sure what this means, but worth pointing out that each month seems to be different. This makes finding a “good” time for a downtime almost impossible.
  • The entire series of these infrastructure load blogposts can be found here.
  • We are still not tracking down any l10n repacks, nightly builds, release builds or any “idle-timer” builds.
  • Anamaria is getting closer to having dashboard reports like this generated automatically – something I’ll rejoice!

Detailed breakdown is :

Here’s how the math works out (Descriptions of build, unittest and performance jobs triggered by each individual push are here: