EU Net Neutrality PSA: It’s not over yet!

Need a quick primer on the importance of net neutrality? I recommend these videos from CGP Grey and Vi Hart.

Early April was a time of celebratory headlines, and for seemingly good reason: the MEPs in the European Parliament had passed a bill enshrining net neutrality in European law. According to the triumphant reporting, it seemed like we could at last relax, whilst throwing sympathetic glances at our friends in the US facing similar struggles. In truth, our celebrations were premature.

The EU is a bicameral legislature: bills must be passed by both of the EU’s legislative bodies before they can become law. We’re only half way there. The bill will now be scrutinised by the Council of the European Union—which, as Wikipedia helpfully reminds us, should not be confused with the European Council, or indeed the Council of Europe: grokking the institutions of Europe is hard!

The council comprises ministers of the member states of the EU. They can either pass the bill as is, or otherwise make amendments, beginning a process of back-and-forth that concludes when a version is reached that is satisfactory to both member governments and MEPs. (A handy infographic explaining the legislative process can be found here.)

This process will inevitably apply to the telecommunications bill. Here in the UK, the government is not happy with the bill’s current form; they are going to demand changes. Now, here’s the rub: we’re about to go to the polls and elect new MEPs. When the amended bill winds its way back to the European Parliament, the amendments will be voted on by a quite different set of parliamentarians from the one which put forward the original proposals.

So, as you go to the polls over the next few days, I would ask you to be cognisant of the position of your local parties and candidates on net neutrality: we need to return MEPs who will continue their predecessors’ work and seal the deal! (You might find the awesome site VoteWatch.eu helpful for checking which way the incumbents voted.)

Happy voting!

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

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.