Reticulating splines

Building cities like it's 1990

Partying like it’s 1999 Building cities like it’s 1990

It started with the release of the new SimCity earlier this year. Sadly, I was only spectator: I doubted my machine could handle it – it’s even starting to creak a bit when compiling Firefox (sad times). I settled for digging out my copy of SC4 and moving on. It continued with the growing drumbeat around the Web as the platform, including as a viable gaming platform. Another element was introduced when I read about a former Mozilla employee’s work on ViziCities. What happens when these swirl about in my head for a while?

Continue reading

Developer Tools GCLI command for emulating CSS media types

I searched Bugzilla last weekend. Nothing new there. I can’t remember what this particular search entailed, but there amongst the results was bug 819930, a Developer Tools bug about emulating CSS media types. It wasn’t the bug I was looking for, though I did read it. I could see it would be a “nice to have” for web developers, but it simply wasn’t an itch I needed to scratch. (My own CSS tweaking efforts tend to be reminiscent of this gif.)

I spent a lazy Saturday evening reading. (Currently: A Distant Mirror by Barbara Tuchman, after listening to an awesome episode of Hardcore History on the Black Death.) At one point, I found myself distracted, pondering “print preview”, which must render pages with @media print rules applied. Later still, another uninvited thought arrived about the View->Page Style->No Style menu item in Firefox. My fate was sealed.

Continue reading

mach uuid

Those of you who hack on Gecko code will know that when changing an XPCOM interface, you need to update the IID. Now, in the dim fog of morning, when I haven’t drunk enough coffee, how on earth am I supposed to remember that the command-line utility for UUID GENeration is named uuidgen? I wish these things had useful mnemonics!

Yes, I could pop in to irc.mozilla.org, and ask firebot. However, I would inevitably forget to /msg firebot, and it is well known that #developers is a hotbed of nefarious sorts, lying in wait to snatch your newly-minted IID and ride off into the sunset, cackling with glee. I could navigate to one of the many online tools, but, sheesh, that sure sounds like a lot of work, you know?

mach to the rescue. I’ve landed a mach uuid command, which will furnish you with a UUID in canonical form. Alternatively, use mach uuid -f cpp for the C++ form.

Happy IID revving!

5 years

December 10th 2007. Bug 399612, comment 1. Graeme McCutcheon appeared in bugzilla.mozilla.org with a modest bit of triage. And so it began.

In truth, it began before that. It began in 2004 with a new laptop, and a download of this new-fangled Firebird browser that I’d been hearing about. It began with faux conviction – “Oh, it’s not from big, evil Microsoft” -  but I was young and naïve.  I used the browser, updated the browser, but filed no bugs, tested no nightlies, waxed lyrical about web standards to no-one. Besides, what could little old me contribute to a big, famous project like Firefox?

Continue reading

Open Badges for contributions to specific Firefox releases

Although I’m primarily interested in Firefox development, Mozilla is more than just Firefox and Firefox OS. There’s a crazy amount of stuff happening! One interesting project is Open Badges. I’m certain this is a right idea/right time moment, given the meteoric rise of sites like Khan Academy, edX, and Coursera (not forgetting Mozilla’s very own Webmaker project), all offering the opportunity for learners to acquire new skills. Indeed, I participated in Udacity‘s first offering of CS101, to observe the mechanics of online learning. (Fortunately I obtained highest distinction – anything else may have triggered a mini-existential crisis!). In fact, I went on to take CS212 Design of Computer Programs (because Peter Norvig!) and CS262 Programming Languages (featuring several Mozillians). Course awards take the form of a downloadable PDF certificate – useful in the offline world for emails and CVs perhaps, but what about online? The ability to showcase your skills online via evidence-based badges is a powerful one.

Separately there is an ongoing focus within Mozilla to grow the Mozilla community and increase the number of contributors to all areas of the project. As a volunteer contributor, this is close to my heart. It may be one of the most important efforts underway within Mozilla. The coding contribute group are wrestling with how to attract, retain and reward coders to the various Mozilla software products. One area of focus is tracking contributors as they reach important milestones in their Mozilla career, and issuing rewards for certain milestones. Open badges have been raised in that context, as a potential reward for certain milestones.

Badges for releases

Aside from individual accomplishments, we hit an important milestone every 6 weeks: a new version of Firefox is released to the world, containing hundreds of patches submitted by contributors in the previous 18 weeks. When your code reaches millions of Firefox users…well, that’s an achievement. That is surely something worth celebrating. Why not issue a badge to anyone who contributed new code to a particular release? By waiting until the release is out the door, we can capture all relevant contributions, rather than trying to measure a moving target like Aurora and Beta. Such a badge could have real value, particularly if backed by evidence – currently if a third-party wants proof that someone contributed, the unattractive options available to them are grepping “hg log” or learning to query Bugzilla. A per-release badge might even be a subtle tool for contributor retention – contributors might aim to earn a badge for every release. Gotta catch ‘em all!

Assessing whether someone has earned a badge for a particular release should be trivial. It’s simply a Bugzilla query – though we need to make sure it’s the right query. This made me curious about the badge issuing process; I was pleased to find it fairly straightforward. In fact, I was quickly able to put together a simple proof of concept, a simple site that will issue a badge to anyone who contributed new code to Firefox 17, with the caveat that the earner will be mightly disappointed when faced with my terrible badge-drawing skills!

Proof of concept

To receive a badge for Firefox 17 contributions, visit graememcc.co.uk/badger and enter your bugmail.

Screenshot of the bugmail entry form

Enter the email address used on bugzilla.mozilla.org

The site then queries Bugzilla, querying if you landed code within the relevant timeframe. The specific criteria are:

  • Assignee == supplied bugmail
  • Resolution == FIXED
  • One of:
    • Target Milestone == Firefox 17
    • Target Milestone == mozilla17
    • status-firefox17 == fixed

If this search finds qualifying bugs, you will be sent to the badge page, complete with awful badge artwork (patches welcome!):

An example badge

A badge is issued – if you earned it! (Note, the badge issued now is actually for Firefox 17 contributions)

The button below the badge allows you to add it to your Open Badge backpack, by signing in to their backpack via Persona, and creating a backpack if necessary. The Open Badges Issuer API takes care of these steps. If you view the badge in your backpack, you can see the associated metadata:

Screenshot of the badge viewed on beta.openbadges.org

Viewing the badge on beta.openbadges.org. Note the evidence field.

An Open Badge assertion contains various pieces of metadata associated with the badge. The most interesting field, the one which gives badges real practical value, is “evidence”. This allows the badge issuer to attach proof that the badge earner has acquired the knowledge or participated in a way that merits a particular badge. Given access to this badge is judged on Bugzilla data, it makes sense to present this data as the evidence. The assertion for your badge is a URL for a Bugzilla query to list all your code contributions to Firefox 17.

Again, note this is just a proof of concept; the badge will expire 28 days after it is issued.

Users that didn’t earn a badge, are directed to a page suggesting they visit whatcanidoformozilla.org to get started!

Feedback

I hope you’ll give Badger a quick spin – and I hope you earned a badge! Remember, this isn’t an official Mozilla badge – such a badge would be far, far prettier for starters – however, the evidence in your badge backpack will speak for itself. I’m particularly interested to here from anyone who did contribute code to Firefox 17 yet doesn’t receive a badge. The search criteria above should be sufficient, however I definitely want to know if they need refining. I would love to hear people’s opinions as to whether this is something worth exploring further.

The code is on github: https://github.com/graememcc/badger

Google Search in New Tab Page

When using Firefox, I realised I am forever performing the sequence Ctrl-T followed by Ctrl-K to start a Google search in a new tab. However, I find the standard new tab page useful, so I didn’t necessarily want to change my new tab page setting (you can change the page by tweaking browser.newtab.url in about:config).

This sounds like a job for an add-on.

My add-on in action

And so I built one. The input is conveniently autofocused, so one can just Ctrl-T and start the search. I guess I’ll eventually want to make things like the search engine configurable, and it’s not particularly pretty, but for now, it’s a great help!

 

Edit: the add-on is now up on addons.mozilla.org.

More m-cMerge updates

A couple more m-cMerge improvements have now landed.

Bug Assignees

m-cMerge will now attempt to set the bug assignee in certain circumstances. Specifically, the following must hold:

  • The current assignee for the bug is nobody@mozilla.org
  • If there is more than one changeset for a particular bug, the changeset author must be the same for each of the bug’s changesets
  • The changeset author email must be a valid Bugzilla user email

The summary page will highlight any bugs where the assignee was set:

m-cMerge summary page with email

When m-cMerge has set the assignee, it will highlight this

Continue reading

Tagged

m-cMerge and status flags

For a while, m-cMerge has been blundering along, ignorant of the various flags our hard-working release drivers use to track fixes across the various trains. It wasn’t alone – a recent thread on dev-planning showed that many developers – myself included – weren’t fully aware of what was required.

Well, now the rules are clear, so m-cMerge has been brought in to line.

Continue reading

Tagged

Handling large backouts with m-cMerge

m-cMerge has been updated regularly since it was unveiled. One recent update added the ability to handle pushes from trees other than mozilla-central. There are plenty of times where large patch series land on integration repositories such as mozilla-inbound, and marking them is as much of a chore as marking merges.

I’ve now taken this to its logical conclusion, and added the ability for m-cMerge to handle backouts as well. You often see sweeping backouts on mozilla-inbound, trying to get the tree back to a green state. Most of the time each of those bugs will be getting commented with the same information – a reason for the backout, and the rev URLs of the backout changesets. That sounds perfect for automation!

m-cMerge will now handle backouts in certain circumstances. Specifically, there can be no fixes landing in the same push, or a fix and its backout landing in the same push. I don’t think we lose anything with these restrictions – you’re unlikely to be landing new code as well as trying to clean up the tree. Equally, you’re unlikely to land a fix and back it out again in the same push – the only scenario where that could happen is a merge, and the backout commenting should already have been done when the backout hit the integration repo.

When given a backout revision, m-cMerge will attempt to attach the relevant bugs to pushes, as normal.

m-cMerge will detect the bugs affected by the backout

As always, the “Add”, “Remove” and “Change” buttons allow for manual review, and correction of anything that has been misdetected.

If you are dealing with a mozilla-central backout, you will be offered the opportunity to reopen the bug.

RESOLVED FIXED? Let me reopen that for you.

Note in this case the “comment” and “reopen” options are linked – you wouldn’t want to reopen a bug without explanation, nor would you post the backout revisions without making the patch author aware he/she was backed out.

You can manually edit the comments if you wish. However, if you need to add the same backout explanation to every bug, there is another solution. When you hit submit, m-cMerge will look at all the bugs whose comment still starts with the changeset URL, and for those, it will present you with the following dialog:

Adding the same explanation to multiple bugs is easy

This will allow you to add some explanatory text prior to the changeset URL. Checking the checkbox will add the same text to any unedited bug comments that have not yet been submitted, and won’t prompt you again. Leaving it unchecked will prompt you to enter text for the next bug when it is ready to be submitted. Hitting ESC or Cancel will transmit the change for this bug without any additional comment text. Leave the textarea empty and check the box to send all comments as they are.

As always, report any bugs in the BitBucket bug tracker. I hope this proves useful.

Tagged

Pushlog URLs now printed when pushing to mozilla-central

When pushing to mozilla-central or mozilla-inbound, one of the first things you are likely to do post-push is copy and paste the changeset URL into the relevant bug. To help, I fixed bug 663585, which has now been enabled on some of our main repositories.

When pushing, you should now see something like this:

graememcc@Vitalstatistix:~/moz/hghooks/fakes/mcclone$ hg push
pushing to /home/graememcc/moz/hghooks/fakes/mozilla-central
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
You can view your change at the following URL:

https://hg.mozilla.org/mozilla-central/rev/b945bf7017be

 

If you’re pushing a large number of changes, the individual URLs cease to be useful. Instead, you will see:

You can view the pushlog for your changes at the following URL:

https://hg.mozilla.org/mozilla-central/pushloghtml?changeset=4464ac64628a

Admittedly this won’t directly, help you with marking bugs, but it’s perfect for pasting into m-cMerge for automating the bug commenting (m-cMerge can now handle general commits to any tree not just mozilla-central).

 

Finally, when pushing to Try, the results of your builds are more relevant. Hence:

You can view the progress of your build at the following URL:

https://tbpl.mozilla.org/?tree=Try&rev=15ecf264d328

 

I hope you find these changes useful!

Tagged