What versions of Activities are shipped with G1G1?

December 4, 2008 – 2:35 pm

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, ed 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, pilule 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, ampoule 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?

Know someone who'd appreciate this post?
  • Print
  • Facebook
  • Twitter
  • Google Bookmarks
  • email
  • Identi.ca
  1. 6 Responses to “What versions of Activities are shipped with G1G1?”

  2. A Tolstoyan epic!

    All wiki pages have history, but it’s unclear to me what page the Software update Sugar Control Panel reads. Is it Activites/G1G1, Activities/G1G1/8.2, ?? It may have changed.

    You could always download the g1g1 clean-install image and look to see what’s on it…

    By skierpage on Dec 4, 2008

  3. When we run Update Activities from the Control Panel, what does it check to see if a particular Activity needs to be updated? Just a time-date stamp, or a version number?

    By Sarah Elkins on Dec 4, 2008

  4. The job of a REAL QA/Test professional is, first, to PREVENT bugs to appear in the product (by influencing the design and development processes), and, second, to find and report the existing bugs and then have to regression test the fixed product.

    Testers do NOT fix bugs. They prevent bugs’ existence.

    By Joe on Dec 4, 2008

  5. Sarah, Skierpage – I don’t know, but I’ll do my best to find out. I hope to have an answer to you by tomorrow. Time to code-spelunk!

    Joe – Fixing bugs is different from getting bugs fixed; without touching a single line of code, you can make sure that a bug gets fixed by advocating for it and making it as easy as possible for a developer to do it (good bug reports, reproduction steps, thanking developers for their help, pointing out the impact a bugfix will have on the project, etc).

    Also, we can’t prevent bugs from appearing in our code. Since we’re an open-source project, bugs in our code are automatically world-viewable. (This is fantastic; it means they can help us find and fix them. Given enough eyeballs, all bugs are shallow.) What we can do is keep those bugs from shipping out in a release.

    By Mel on Dec 4, 2008

  6. > Also, we can’t prevent bugs from appearing in our code. Since we’re an open-source project, bugs in our code are automatically world-viewable.

    This is a really good point. Furthermore, “our” code isn’t even ours — 90% of the software we ship was developed by people we don’t know and will never meet. I agree entirely that “let’s make sure bugs never appear in our code” isn’t the appropriate mindset.

    By Chris on Dec 5, 2008

  7. It turns out I was wrong, we do release customization keys… perhaps we just need to label them as such in a README.txt. See #9071.

    By Mel on Dec 5, 2008

What do you think?