Archive for the ‘Mozilla’ Category

Fear and Loathing in Whistler

July 31st, 2008

Day 4. It’s another gloomy day out there. I was awakened by the sound of a generator outside my window and an ill-sounding alarm buzzer coming from the room safe as the power drained out of it, locking my documents inside. There’s no power in the room. The hotel is running on emergency power after a truck drove into a transformer outside, knocking us back to the 1800’s. Fortunately, this Edwardian mountain resort still has the internet — at least for another 10 hours, anyway.

Despite all the catastrophes and confusion, the summit’s been a great success. We spent yesterday afternoon locked up with various platform guys talking about how to improve Firebug and getting the scoop from John Barton on the state of things. For those still in Whistler, I believe we’re still planning on having a talk this afternoon at 2:15 in Alpine C. Assuming the wolves haven’t taken over by then. You’ll see the wolves soon enough.

Tags: , , , , ,
Posted in Firebug, Mozilla | Comments (2)

The Correct Term is “Firebuggist”

July 17th, 2008

After the Firefox 3 Release Week excitement, I kind of zoned-out for a bit and forgot about my blog. In an attempt to re-invigorate it, I’ve updated the theme to something a little less “newspapery” and should be able to get it looking a bit better than it did out of the box. It’s a work in progress and some things still don’t look quite right, but I have Firebug to help me fiddle with the CSS and layout. Nixing all instances of “Arial” was a good place to start. Also, while I’m rambling on about my blog, I should mention that WordPress 2.6 is out and if you’re using that platform, you should really update. Trust me, it’s nice.

Speaking of Firebug, it looks like I’ll have plenty of opportunity to play with it now as I’m going to be helping out with that project full-time. I’m really excited to be working on development tools again and already have a few ideas for features or extensions. (Internet-famous) John Resig posted a great article a couple of weeks ago and I’m looking forward to working with him, Jan Odvarko and the Firebug team to make it the awesomest, standards-based web-development tool in the universe. I’m hoping to write another post in a few days about some of those ideas. In the meantime, I have a couple of little patches to finish up before completing the move.

From an organizational perspective, this means I’ll be moving into the Evangelism Team with Mike Shaver and friends. I’ll still be helping field questions about the unittest infrastructure if they come up, but inquiries and bug reports should go to John O’Duinn and his team of Excellent Release Engineers.

Thanks to everyone for making this shift possible and to everyone who sent congratulatory notes. Everyone is Awesome! :)

Tags: , , , , , ,
Posted in Firebug, Meta, Mozilla | Comments (6)

Firefox 3 Download Day!

June 17th, 2008

airmozillaOur crack team of experts is still working on getting the web infrastructure fixed up. In the meantime, I’m going to be posting stuff to my flickr stream all day in the Firefox 3 Release Week set.

Tags:
Posted in Firefox, Mozilla | Comments (1)

Firefox 3 Unittest Architecture

June 6th, 2008

Now that we’re on the verge of shipping Firefox 3 to hundreds of millions of users around the planet, and getting ready to move our development efforts into new territory on a new repository, it’s a good time to talk about the tireless robots that have diligently checked every source change for nearly a year and a half. They’ve worked hard, been yelled at, called names and had tense discussions with developers and IT personnel during that entire period. Some have passed on, retired to the quieter pastures of staging or have been melted down for scrap. A couple of die-hards survived relatively unscathed and are looking forward for more action, their scars worn like badges of honor…

unittest diagramOk, that’s laying it on pretty thick, but I have a fond affection for a few of these machines. For instance, qm-xserve01 was the original Mac unittest Xserve and nothing else has been able to touch it for compile and test time. We recently dropped qm-xserve06 onto the farm and at best, it’s about 10 minutes slower end-to-end than xserve01. I don’t know why this is and it shouldn’t be - xserve06 is newer and sporting more recent processors and I believe a faster bus. See also qm-win2k3-01, our first physical box running Windows unittests. It’s been there since April 26th of last year, as Shaver once quipped, “qm-win2k3-01 taught me to love”. We’re still waiting for the t-shirts.

Why are there three of everything? We borrowed a trick from Talos. One of the difficulties of running a testing box is that you sometimes get funny results. There are a lot of moving pieces on these machines and we try to keep them as tight as possible, running as few extra components as we can on identical operating systems (across a single platform), but sometimes things just go a little funny. The thinking was having sets of three (triadic) machines would introduce some error-checking into the runs. One orange run out of three can be discarded. Two out of three and you might have something a little harder to reproduce. Three out of three and you close the tree and backout. I think that system works pretty well in most cases.

The one sad point we’ve really struggled with during this period is the linux platform. We’ve been running linux unittests on our Centos5 ReferencePlatform which is solid and well-maintained by Ben Hearsum and Nick Thomas. Running it on VMs introduces some variability that has been really hard to shake down. Tests involving timers are almost guaranteed to fail at some point. Sometimes, if disk access gets a little busy, we see errors in reftests loading some resources, usually pngs of even the smallest size. Then there are the random mochi* failures. These problems are hard to reproduce and even harder to diagnose, usually resulting in a shrug and someone shakily pushing the “force build” button on the waterfall page in the hopes that the problem will go away on the next build. It often does.

If you can shed any light on these on-going issues, we could use some help. Please see bugs:

Moving forward to mozilla-central, we’ve got a few machines chugging along there and I hear qm-win2k3-03 picked up its first real regression yesterday so things seem to be progressing nicely. Over the next few weeks, we’re going to give the Firefox3/Gecko1.9 machines a spit-polish, upgrading all of them to buildbot 0.7.7 and matching their installations to what we’re using on the new machinery. As for what the new machinery will look like, I have a sneaky suspicion it’s going to look a little bit like Talos.

Tags: , , , , ,
Posted in Infrastructure, Mozilla | Comments (4)

Add-ons I can’t roll without

May 26th, 2008

Deb posted an excellent run-down the other day about 20 top-notch add-ons ready for Firefox 3. I thought I’d do a quick write-up about a few of the add-ons I find invaluable too (and more-or-less ready for Firefox 3.0). Note that there may be some overlap here and that some of these add-ons are considered to be “beta” versions and come with all the warranties that term implies. Without further a-do, I present the add-ons!

Scribefire

This post is written in it. Over the past few weeks I’ve been using this blogging extension more and more often. It’s been getting updated frequently as Firefox has shuffled through the beta cycle and feels ready to go now that they’re up to version 2.2.5. It also includes a number of other useful features including some features like the award-winning Share-o-holic for posting pages to Digg, Reddit and Magnolia, to name a few. The best part of Scribefire is that it keeps my blogging right in my webbrowser. This feels right to me.

Twitterfox

My favorite way to twitter (when twitter is working)*.

Delicious

At long last, the del.icio.us add-on has been released for Firefox 3. It’s still in beta, but I’ve been using it for a couple of weeks now and feel that it’s an integral part of my browser.

eBay Companion

Hardcore eBay addicts will appreciate this. It lets you keep an eye on your watched items and provides a little extra security when logging into an eBay or Paypal site. It has helped me acquire many tiki mugs this weekend at some expense. I considered that “doing my part for Firefox 3″.

Lastly, I’ll mention a few quickies that I really like. It’s time for…

Robcee’s Add-ons Honor Roll!

Fission - progress bar in the title bar. Safari-style.
QuickRestart - restart your browser. Quickly!.
CustomizeGoogle - modify how you work with Google. Force https connections for mail, etc.
Adblock Plus - ads were 10 years ago.

Technorati Tags: , , ,

Tags: , , , , ,
Posted in Firefox, Mozilla | Comments (5)

HOWTO: Unit testing Linux

May 22nd, 2008

Mozilla’s evangelist and resident all-around-good-guy Chris Blizzard wrote an excellent piece yesterday on the dangers of hand-picking patches in a linux distribution, at least as they pertain to Mozilla and Firefox. I don’t need to say more on that as he covers it pretty well. I will just say that it’s a hard problem and difficult to get it right without having the entire big picture spread out in front of you.

I’m writing this in the hopes that we can make the process a little easier for those of you responsible for packaging Firefox (and hopefully other Mozilla apps down the road) on Linux.

First, the background: We do automated unit testing. We do it on every checkin and you can see the results posted to http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox. The machines responsible for producing those results are running buildbot. We’re currently using, a slightly customized version 0.7.5 (available from Mozilla’s cvs repo at cvs-mirror.mozilla.org in mozilla/tools/buildbot, branch BUILDBOT_BRANCH_0_7_5) on top of Twisted 2.4.0. Soon, we’ll be moving forward to version 0.7.7 and Twisted 8.x on all our machines as part of a Grand Unified Vision. More on that later.

We have some scattered documentation around the mozilla wikisphere that we’ll be consolidating and cleaning up over the summer. The important bits are: the main Mozilla Buildbot Wiki page at http://wiki.mozilla.org/Buildbot. Of some but decreasing importance is the BuildbotTestFarm setup page. It has links to the important buildbot master configuration and setup files, namely master.cfg and mozbuild.py in the unittest directory. Also, http://wiki.mozilla.org/BuildbotTestFarmUse has a really awesome diagram that I created (and recently updated!) that you’ll want to show to all your friends and possibly print out and hang on your cubicle wall.

Ok, let’s use all this to setup an example buildbot master and slave on your linux environment of choice. First, we’ll assume you’re capable of actually building the browser on your slave machine according to Linux_Build_Prerequisites. On your buildbot master (it can be the same machine as the slave if you’re just doing a single builder), create the master directory by typing “buildbot create-master unittest_master” (where unittest_master is your directory name, it can be anything). Copy master.cfg, mozbuild.py and the default mozconfig file into this newly-created directory and modify the .cfg file to taste. If you’re doing a straight copy and paste from our version, you can delete all those extra machine names and will have something that will look more like this: master.cfg. Rename URLs and links as appropriate. If you don’t use Tinderbox server for hosting your builds, you can remove the “c['status'].append(tinderbox.TinderboxMailNotifier(…” section entirely and just use the buildbot waterfall.

Once you’ve got that setup, start it up by running “buildbot start unittest_master” in the parent directory and you should see some log chatter as it starts up. You can verify by visiting localhost:2005 on the master machine and seeing a waterfall with an empty table in it. It’s waiting for a slave to connect. If you don’t see this, you’ve done something horribly wrong and will need to start from scratch, probably after thinking about it for a few minutes and maybe getting a cup of your favorite caffeinated warm beverage. This thoughtful reflection is important. I can’t stress this enough!

Now that you’re properly caffeinated, let’s create the slave. I’m going to assume you’re running it on the same machine as the one you’ve just created the master on. In a nearby directory, type “buildbot create-slave slave-dir localhost:9989 linux 1h34rtL1nuX”. It should create a directory named “slave-dir” and add a few files to it. Now the fun part: type “buildbot start slave-dir” and you should be up and running. Verify this on the buildbot waterfall page where you should see the slave connected and a build starting up.

At this point, I’m going to finish up with a few caveats. These instructions assume you’re using the same buildbot version we’ve used for these setups (version 0.7.5 running on twisted 2.4.0 with python 2.4 or 2.5). You’ll need to modify your master.cfg file slightly if you’re using a newer version. For excruciating details on how we setup these machines, see http://wiki.mozilla.org/ReferencePlatforms/Linux-CentOS-5.0. All machines running Reftests are required to have 24 or 32bit displays for image comparison. Lastly, the test machine will have to have run any version of Firefox before for the default profile to have been initialized.

The file “mozbuild.py” mentioned above contains the interesting bits. If you’re curious about how to run any of the individual unittests from a run, be sure to take a look in there at the “command=” parameters to the various testing classes. Good luck, and have fun!

Tags: , , , , , ,
Posted in Mozilla, Testing | Comments (1)

Moz2 UnitTesters

April 29th, 2008

Echoing coop’s launch of the leak/debug machines on the Mozilla2 page, I landed three new boxes today each running unittests.

These are still a work in progress and I’m still sorting out how clobbers are going to work (clobber files will live in Mercurial under http://hg.mozilla.org/build/buildbot-configs/mozilla2-unittest) as well as a few other hg-related end-pieces.

Lastly, a couple of other notes about failures, the Mac (OSX Darwin 9.2.2… qm-moz2mini01) and Windows (qm-win2k3-moz2-01) machines landed in a state of orange. Both are reporting reftest failures and will need some looking into.

Please file bugs machinery-related bugs against mozilla.org::Release Engineering.

Tags:
Posted in Infrastructure, Mozilla | Comments (0)

Planned unittest outage April 3, 2008 @ 7pm PDT

April 3rd, 2008

We’re going to be adding a few new machines to the production unittest set. We’ll be adding two new Windows 2003 boxes to add a little redundancy there. Additionally, we’re going to be adding a Windows PGO unittest machine to test that the optimized bits aren’t doing anything they’re not supposed to be doing.

See the details in bugs 420073 and 419759.

Many thanks to Mikeal Rogers for setting up the PGO box (twice!) and to Coop for slaving over the hot Windows ovens.

Tags:
Posted in Infrastructure, Mozilla | Comments (0)

AwesomeBar Awesome Feature #832

March 28th, 2008

A friend of mine mentioned how awesome the new Firefox 3 beta is last night while we were playing a little Halo. “I know,” I told him, maybe a little cockily.

Undeterred, he plowed on, “the best new feature is, you know how you can collapse the toolbar and location bar on the Mac? With that little capsule button in the corner?”

200803281644.jpg

“Yeeaah,” I offered, eager to hear where this was going, figuring he was going to say something like, you know it makes the browser area bigger, right?

“Well, now when you’ve got it collapsed, you can hit Cmd-L and a little Location Bar drops down.”

I let this sink in for a minute, realizing I was in uncharted territory.

“You mean I can hit Cmd-L and a Location Bar appears out of nowhere?” I asked incredulously.

“Yeah! It totally saves all kinds of space on my MacBook!”.

“O.M.G.” I think I said.


200803281645.jpg

So, yeah, that little useless capsule button? Not so useless anymore. And having the full awesome power of the AwesomeBar available on Cmd-L in a collapsed toolbar? I can’t even tell you how cool that is.

Posted in Firefox, Mozilla | Comments (15)

Mochitest By The Numbers

March 27th, 2008

In an email discussion yesterday, Schrep posed the perfectly cromulent question, how many unittests are we running and where did they come from? A good chunk of our testing comes from a few popular JavaScript programming libraries that some of our more intrepid test coders translated to run inside Mochitest. I knew we’d translated jQuery, Scriptaculous and Mochikit’s own test frameworks, to name a few, but what else was in there? And what portion of the 50,000 odd mochitests were from large external frameworks?

I spent the afternoon grabbing a new tree and running through a Mochitest run and looking at the output in Numbers. What follows is my simple analysis of the contents of Mochitest on Mac – the numbers are slightly different for other platforms but comparable.

I want to be clear that these numbers may be slightly misleading. I can’t point at a single one of these and say with utter certainty that “that is a single unittest”. When we asked David Baron about the 20-odd-thousand tests included in Layout/Style, he told us:

There are a bunch of tests that test things combinatorically. In other words, for a long list of potential values for CSS properties, testing a large number of things related to that value’s parsing, serialization, and computation through different APIs.

Rob Sayre also had a note of caution regarding these figures:

The definition of what constitutes a single test is pretty fluid. I would just say “tens of thousands”

What we can say then, with some certainty is that Mozilla contributors have written, constructed or otherwise created tens of thousands of unit tests in just over 1 year. We’ve also outnumbered the external tests included in our test code by nearly 10 to 1. Areas we’re testing include, but are by no means limited to: content, canvas, layout, chrome, docshell, HTML parsing, XUL, … really too many areas to list like this. See the analysis doc for details.

I think this is a phenomenal achievement and would like to thank everyone who’s contributed. Clearly Mozilla has become a very test-focused project and this has enabled us to create better builds with demonstrably fewer regressions on nightlies and betas.

There’s always more to do. The external test-suites we’ve included could stand to be updated and augmented. Below are a set of bugs John Resig recently filed. If you’re a developer looking to hone your mochitest skills or want to contribute to our growing population of tests, pick one of these up and take a crack at it.

Tags:
Posted in Mozilla, Testing | Comments (1)

« Older Entries