Its late, but I’ve just finished upgrading my wordpress install. The previous install was so out of date that none of the usual migration guides would support it anymore, so I had to hack around the previous data in SQL to get everything carried over correctly.

At this time, I *think* all the loose ends are sorted out, except for some missing categories on pre-existing posts. If I’ve got it right, you should see this post on planet.m.o as usual, and all the pre-existing links should continue to work fine. However, if you notice something that I missed, please let me know, ok?

(also – what do you think of the new theme?)

Since the AllHands, we’ve held this brownbag with a few different groups. Each time, we tweak it further based on comments and questions asked. There might still be further changes, but at this point, it was worthwhile updating the PDF in this blogpost.

If you are interested in being an early “tester” of this BrownBag, let me know – I’d be happy to hold a brown bag session and go over it anytime. Also, if you have any comments about this PDF, please let me know. 🙂

Late last week, we finally completed a long running project: we found a new, better, home for our growing array of mobile phones in our continuous integration pool. Here’s what I presented at the weekly Mozilla Foundation call Monday morning about that project, hopefully it makes sense.

1) Each checkin gets:

• 40 hours of build/unittest/talos on a desktop computer, and

• 25 hours of unittest/talos on mobile phones.
• Instead of one phone doing 25 hours of testing, we could have 25 phones each do one hour of testing. Or 50 phones do half-hour of testing…
• we get 100-120 checkins per day – that is a lot of phones.

2) Phones are really sensitive to wireless noise

• interference causes intermittent orange/red test results, also manual hang/reset work for RelEng.
• Building K office was better, because we were far from anyone, but the new office is in downtown Mountain View, and has lots more wireless noise.
• To fix this, we built a “faraday cage“, a shielded room to eliminate outside wireless interference. Wikipedia has a great description and diagrams, if you follow that link.

• Hopefully this should give us better stability for tests results. Time will tell.

3) How to arrange the phones in the room

• lots of running devices, each transmitting radio signal. We’re planning for at least 400 phones all fitting inside the wireless room, so how to deal with cross interference. Not big enough to just arrange on desks / floor like we did while we were waiting for the Faraday cage to be built. Have to think 3D.

• however, hard to attach to walls, cannot puncture walls – cannot breach cage.
• whatever we do use within the room must be non-metallic, to minimize wireless disruption within the room
• phones cannot be *too* close to each other, early testing with cross-interference showed failures if bunched too close.
• as the number of phones increases, we might find more cross-interference, so whatever we do needs to be possible to move around.
• must not touch the front / sides of the devices, which might accidentally press a button
• must be easy to see the screen on the running phone
• tolerant of heat, either from the phone or the phone charger
• easy to take dead phones out, open, remove batteries, reimage and replace (we do this ~10 times per week)
• must be compatible with phones we haven’t bought yet

4) How did we solve it?

• BedBathandBeyond.com sell rolling mobile bamboo garment racks, which can be assembled with 20 screws each. These can be assembled in minutes.
• They also sell hanging shoe racks which velcro to the cross-rail, are made of heat-resistant fabric, have plastic as a firm base to each shelf and hold 20 phones each.
• Each garment rack can hang 40 phones (two shoe racks with 20 phones each). The power strips rest on the bottom wooden shelf and run cables up the back of the shoe racks. In this photo, you can see racks for 120 phones, of which 90+ are already in use.
• Bonus: each shoe phone is about 3-5 inches apart from another phone in adjacent shoe rack, which is the same spacing we had when the phones were just arranged on some empty desks in the office.

5) Brought to you by: aki, dmoore, jhford and mrz.

• They all did *tons* of invisible behind-the-scene work to make this happen. Every time you see a mobile phone reporting test results on TinderboxPushLog or draw a dot on GraphServer, give thanks to aki, dmoore, jhford and mrz.

• If you are curious for a video of the very quick presentation (3.5 minutes, according to Jono and his stopwatch), see Monday’s Mozilla Foundation weekly call here. I mention it in case the video is easier to follow the verbal with hand-waveing vs this blog post.

A quick introduction.

Rail has joined Release Engineering, and will be based in Moscow.

Some of you may already know him from his automation work in the Turkish and Russian locales for various Mozilla projects including Firefox. Or maybe you know him from his work in openoffice.org, or debian, or pootle. Anyway, he’s been using his skills in automation to make each of those better, so we’re delighted to have another like-minded automation person joining RelEng.

On irc you’ll find him as “Rail”, which is pronounced “ray-eel”.

(Oh, for the curious – he’ll be based in Moscow, as Toronto is “not cold enough” for him right now!)

If you use our xulrunner builds, you know we provide builds for xulrunner on the 1.9.0, 1.9.1, 1.9.2, mozilla-central and lorentz branches. Almost all of these xulrunner builds are produced through the same pool-of-slaves that are used for Firefox – except for the oldest xulrunner1.9.0 which are still being produced the old way – on dedicated unique machines.

This blog post, as well as mfinkle’s blog post here, the dev.platform newsgroup posting here and the discussion in the Platform meeting on 27jan2010, are to let people know we’re planning to stop xulrunner builds and releases on the 1.9.0.x branch. This would only affect Mozilla building and releasing xulrunner 1.9.0.x. Mozilla will continue to build and release xulrunner from the 1.9.1, 1.9.2, mozilla-central and lorentz branches. Obviously, the source code to xulrunner 1.9.0.x would remain available and developers could always build and release their own xulrunner 1.9.0 packages from the source code if they wish.

While considering this, we realized that we don’t know how many people are using which branch of xulrunner; further, we have no idea if people are using pre-built xulrunner or building their own. If you are using xulrunner1.9.0, please let us know in the newsgroups if this will impact you either way. Meanwhile, unless there are objections, we’ll continue preparations to stop xulrunner 1.9.0 builds in bug#544678.

As you all know by now, on Friday we released Fennec1.0. The new features and improvements are already being covered by other people in great detail, so I thought I’d focus on something totally different that happened behind the scenes for this release.

Lots of things were unique about Friday’s fennec1.0 release, but here’s the three that stuck out in my mind.

1. Automation on mobile phones is much trickier then automation on desktops. See blogposts by jhford, aki and occaisionally myself on all the fun with imaging, setup, automation, scaling, calibration of all these machines. There’s still more work underway with new phones and new platforms – stay tuned!

2. Fennec1.0 included a multi-locale version, which we believe is a first for Mozilla.

   Until now, whenever time we shipped localized versions of a product, each separate download contained only one localization. If you wanted a different locale, you downloaded a different installer – or if you were savvy enough, you could tinker with some add-ons to switch xpi files. Historically this kinda makes sense on a desktop computer, and allowed us to save on download size, and improve first-time out-of-the-box startup time. However, an application installed on a phone could be shipped to a range of locales, so “multi-locale” was born. The basic idea is to detect the locale of the host OS on first run, and if that locale is one of the locales supplies in multi-locale installation, use that. There are tons of edge-cases though, which made for lots of fun, but I think it was well worth the effort in the end. The multi-locale version of fennec1.0 included 12 locales (cs, da, de, es-ES, fi, fr, it, nb-NO, nl, pl, pt-PT, ru). There are also 38 different single-locale versions of Fennec available for individual download.

   With this now proven to work in Fennec1.0, if you feel we should do something similar for Firefox, please comment below, or here, or in bug#485861

3. As part of all this, we had to learn how to get deb files generated at the right step in release automation, and how/where to host these deb files in order to make them useful. We will be reusing this knowledge.

Enjoy Fennec, and let us know what you think!

ps: the cake was great!