The job of a tester is to get bugs fixed. Here's a look at how I'm trying to get a couple going.

"What version of the Measure Activity was shipped on this year's G1G1 machines?"

It was a simple question from Arjun, Measure's maintainer. This should be easy; it's reasonable that an Activity maintainer would want to know what version of their work is being used in a release, and you could imagine an XO user wanting to check what version of an Activity they'd get on their machine if they clean-install upgraded to the G1G1 image.

Through the process of answering this question, Chris, Bert, and I learned that it wasn't a simple answer - but it should be. Here's how the system works right now, why it's broken, and what we've proposed for fixing it. In the process, I began to learn about the mysteries of OLPC's software build system.

A bit of backstory: on your XO, you're probably running an OLPC build, most likely one of the builds designated as a release. For instance, build 767 is release 8.2.0. An analogous situation would be publishing a book; you might have many drafts (builds) of a book, but every year or so you pick a good recent draft you've finalized and say "this is what we're going to publish as the 3rd edition (release) of this book." Builds are made of packages - think of them as chapters included in a book. The OLPC build you're running includes packages for the Fedora-based OLPC OS and the Sugar UI (and other things).

On top of this, you have Activities, or what most people think of as "the games that you can play on your XO." Builds and Activities are separate. (This wasn't always the case - and it's led into problems for us today. More on that later.) The idea is that if you're deploying XOs at your school, you'd choose the Activities you want for your particular deployment/school/classroom instead of being forced to accept a default package of Activities that might not fit your individual needs.

To do this, you'd first install the build, then use customization keys to put the Activities you want on the XOs you have. The analogy breaks down a bit here, but you could imagine Activities as a bunch of stickers you've applied to your book's cover, and a customization key as a sheet you've made with all the stickers that you wanted on your book, so you can peel-and-stick it as a single thing. So you've got a build with Activities - or a book with stickers on the cover - and the entire shebang together is called an image.

Usually, OLPC lets people "sticker their own books" - pick a release, install it, pick Activities, install them, move on happily with their XO-using lives. For G1G1, we ship pre-stickered books. Arjun's question can therefore be phrased as "what verison of my sticker went out on the books you shipped?"

Here's where the problem comes in: the process by which we create G1G1 images (the pre-stickered books) is manual and undocumented. This leaves Arjun with three places to look to answer his question.

He could look at the wiki page. This is probably accurate, but isn't guaranteed to be, since it's manually updated/edited. I could edit, right now, that page to say that every Activity shipped with version 42, which would be a crying lie.

He could look at an XO. Arjun could download the G1G1 image, install it on an XO, then go into that XO and look at the Activity version number in the files there. this is accurate, but not optimal. It consumes a lot of time and bandwidth and assumes he has a spare XO to reflash for this purpose, which is not the case for many developers.

He could look in the build.log for the image. This is what ended up happening, and it would be great - except for one thing. The G1G1 image with Activities doesn't have a build log. That build log I've just showed you is for the build within the G1G1 image - the book without the stickers - and it has no information whatsoever about what Activities are on the image itself, since the build and the Activities are totally separate things within an image.

If you look through that file, though, you'll see what confused Arjun; there's text in there that looks like it's information about Activities. Stuff like this:


16:25:29 URL:http://mock.laptop.org/repos/local.8.2/XOS/Measure-12.xo [20330] -> "Measure-12.xo" [1]
16:25:29 URL:http://mock.laptop.org/repos/local.8.2/XOS/Measure-13.xo [20118] -> "Measure-13.xo" [1]
16:25:30 URL:http://mock.laptop.org/repos/local.8.2/XOS/Measure-14.xo [26059] -> "Measure-14.xo" [1]

If I was Arjun, here's what I'd be thinking. "Wait, this build log has stuff about Activities - it must be the build log for the G1G1 image... and it's telling me that they put an outdated version of my Activity on thousands of XOs - oh no! PANIC TIME!"

What happened? Well, remember how I was talking about builds and Activities being separate, and how this hadn't been the case in the past? Yep. This is an old, dead artifact. While creating a build, the build system still downloads old Activities; it just doesn't actually put those Activities in the build. So there's stuff about Activities in the build.log despite the fact that Activities aren't anywhere in the build itself. And as we've seen, this can be confusing.

The solution is pretty simple. The answer is that we need to say that...

  1. This is not the document you're looking for. (filed bug #9070)
  2. The document you're looking for does not exist
  3. However, it should exist; let's create it. (filed bug #9071)

Does anyone want to help fix these things?