Nifty addition to treeherder

At work I just found out we have a nice change in Treeherder, the tool that monitors current Firefox (and other) builds. Without writing my usual 10 pages of explanation and backstory, I’ll just say that Treeherder shows whether the release engineering infrastructure has started the release promotion process to take the builds from the changeset specified and do some super mystery magic on them to make them suitable for actual release to Firefox users. We get an email from the notification system that this happened, but now we can follow along in the same tool we use to watch tests pass or fail.

gecko decision task for firefox and fennec

In this case, I used a different tool (Ship-It) to set up the parameters to take the test builds for the 1a24837f9ed232d8d2dc4535d11ee53c9847b109 changeset (say it 6 times, fast) for Firefox 59 beta 7 (plus the android and developer edition versions) and declare us ready to kick off this process. Instead of checking email notifications that only go to a particular mailing list, or diving straight into TaskCluster, I can see that near the end of the enormous list of automated tests running on various platforms, “Gecko Decision Task”. This tells us that the builds are now being “promoted”. I haven’t tried drilling deeper yet, but if you click on any of the links there (such as “promote_firefox”) then you get even more detail, including links to TaskCluster and its myriad, confusing joys.

As usual, I think it’s damn cool that all this happens “in the open” at Mozilla, so you don’t even have to be logged into anything to see quite a lot of detail. Anyone with an interest can learn a lot here, or even get involved and contribute, because of this level of commitment to transparency. It’s a good way to find out if you like the work, or to get work experience that you can easily show off in the future.

Mozilla Summit 2013: bugs, crafts, and fun

The Mozilla Summit in Toronto was a lot of fun. I met so many intense, idealistic, motivated open source contributors, it made me feel renewed energy for my own contribution.

On the first day I heard some of the keynotes but missed Mitchell Baker’s keynote on the Nature of Mozilla, which I’m going to watch today. People were talking about it through the rest of the conference, so I’m curious.

The talk I did was called Awesome Bugzilla Tricks and was a fairly short presentation of some tips for using Bugzilla.

As we went through these tips, the talk turned often into a good discussion of how people use these features of Bugzilla. We thought of a new way to implement Bugzilla tags to look more like browser bookmarks.

People talked about their own workflow as we went around the room describing what we do with bugzilla.mozilla.org! That is usually my favorite part of a workshop level technical discussion. It is like a series of sharing mini-demonstrations about actual working process, what we use and what we do and why. That is very illuminating. I realized in our discussion that I was talking with Kohei who made bzdeck, a tool that makes reading Bugzilla.mozilla.org bug reports more like an email inbox. I had particularly wanted to meet him so was very happy he came to the talk and the discussion! 😀

Durng the talk I said something a little weird and abstract that was not in my slides, inspired by the discussion. Here it is…

As a literary critic I find it fascinating that it is a huge collection of textual information which we engage with as authors and readers. It is like the ultimate “difficult work”, like reading James Joyce except 900,000 times better and with a more interesting result. There is no way to make it easy to understand, even if you can make little pieces of it easier to use and learn, the underlying information and tasks are beautifully complex and demanding for anyone who engages with it, which means you can’t fail to learn something if you try.

Then, luckily, we went back to talking about practical things, features, dashboards, and workflow.

The other main activity I did at the Summit was to set up a big table with craft supplies. Based on an idea of Lukas Blakk’s, I set up beads, string, and charms shaped like ladybugs, dragonflies, bees, and beetles so that people could make necklaces, bracelets, and other wearable souvenirs. The beads had numbers and letters so that you could spell out the number of your favorite bug.

People did just that!

I loved seeing people think about what bug was their favorite or most important to them personally. Sometimes a first bug, or one that people were proud of fixing, or one with an important, complicated discussion. Several people told me that during the Summit, they looked up other people’s favorite bugs from the bug bracelets, and learned something interesting.

Bug 356038 was represented by number and by its Bugzilla alias, BCP47:

BCP47

Rust and Github bug #5677, ‘Rustpkg “ready for use” metabug’ got some love:

Tim with Rust bracelet

Vu gave a shout out to bug 780076,

bug bracelets

And here is another bracelet featuring bug 808964,

Bug 808964 bracelet

For my own favorites I made three objects, one a wire necklace for bug 923590, “Pledge never to implement HTML5 DRM”, and a bracelet and a barette with my first patch because I was proud of submitting a patch. The EME or DRM issue was discussed very intensely on Sunday by many engineers. Feelings definitely ran high and people were determined to continue discussion. I was glad it got an official slot in the schedule for discussion and that there was widespread interest.

Favorite bug maker party

Bug 298619 was put onto a cell phone charm along with a blue and orange glass bead shaped like a beetle!

bug-charm

Many other people made Mozilla or MozReps necklaces, spelled out their names or their loved one’s names, with bug charms, or with wire, like this beautiful and creative copper wire creation:

copper wire necklace

And this Maker Party necklace!

Maker Party!

This resulted in “conference swag” was personal and made on the spot, worn and also given as presents! Many people commented that they felt soothed and comforted by hands-on activity in the middle of intense social interaction. I observed that people discussed what bugs or words to spell, how to design their objects, and what techniques to use, very collaboratively, so it was a nice physical representation of work and process.

Mozilla Summit crafts

After the first day, I left the craft station open 24 hours in the lounge, replenishing it with beads from West Queen Street on day 2 becasue we ran out of the letters Z and A, popular in spelling out “Bugzilla” and “Mozilla”. Of course this was because we were in Canada, where they use a lot of “eh”!

I would do this again at a conference, and now I know from experience what supplies are needed and which things are likely to be popular.

The other silly and fun part of the conference for me was wearing (and lending to people) the brainwave controlled robot fox ears! The looks on people’s faces, so priceless, as they realized the ears were really moving. Everyone who tried it laughed very hard!

ears!

robot ears

Thanks for a great and inspiring Summit, everybody!