@graememcc

Published 21 May 2014

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!

Published 27 October 2013

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?

Published 20 June 2013

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.

Published 17 June 2013

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!

Published 10 December 2012

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?

Published 28 November 2012

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.

Published 9 October 2012

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.

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.

Published 21 September 2012

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:

Published 14 September 2012

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.

Published 7 August 2012

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.

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.

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:

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.

Published 5 August 2012

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!

Published 12 June 2012

In the summer of 2011, the integration branch mozilla-inbound was created, to allow Mozilla contributors to land patches without having to wait multiple hours afterwards waiting for your builds to complete. A team of inbound-sheriffs monitor the tree, dealing with failures and backing out where appropriate. About once a day, one of the sheriffs would merge the changes to mozilla-central, and after the merge spend the next 90 minutes marking the bugs as resolved and pasting the pushlog URLs into each bug's comments. And thus your patch made it to mozilla-central!

Wait a minute, after the merge the sheriffs did what?!?

We have some smart people acting as inbound sheriffs. This does not seem like the best use of their time. It always bugged me, even though I've never merged myself. I wanted to do something about it. However, I felt it would be difficult to fully automate - even with our current restrictions, a wide variety of commit messages is possible. Accurately parsing them 100% of the time would be...hard. Throw in security bugs, and inbound's propensity to get so hosed that it has to be closed for a bit of "BACK OUT ALL THE THINGS!"...

That said, I didn't think all was lost. As Kernighan and Plauger said, most users will be willing to meet you halfway, and be ecstatic if you manage 90% of the work.  I decided to see if we could get 90% of the way there.

Read more

Published 17 May 2012

I'm still working on something to assist those merging to mozilla-central.  I'm almost ready to start talking to Bugzilla.  Obviously, one can't test on b.m.o, so off to the test server - Landfill - we go. Now, I'll need to handle security bugs, and users who may or may not be able to modify them. I emailed Gerv, to see if it would be possible to emulate the b.m.o. security bug configuration in the bzapi sandbox. His reply? Sure you can, and have some admin privileges so you can set things up as you wish.

Published 3 May 2012

I've been reminded that I've not been poor at updating the blog. Mea culpa. Anyway, some recent fixes of note:

• Bug 686203 - Focused contenteditable can prevent other elements from getting focused on right-click, which also fixed bug 578771 and possibly more!
• Bug 740784 - Undo (Ctrl+z) in textarea adding a newline (\\n) to the text
• Bug 747163 - TelemetryHistogramType returns failure for HISTOGRAM_FLAG
• Bug 747379 - Cloning a flag histogram with Telemetry::HistogramFrom breaks the "only one count" invariant

Published 15 January 2012

A frustrating week, with a good chunk of it lost to the landing of bug 715952, which seemed to tickle a bug in my graphics card driver, resulting in a crash almost every time I tried to launch a trunk build. Spent a ridiculous amount of time sshing into my box trying to remote-debug the problem, with little success. The problem was solved by an upgrade of my driver to the latest ATI proprietary drivers, but that was somewhat hairy, and proved to be another timesink.

• Have slowed down my Tinderboxpushlog investigations - the bug I was trying to solve is looking more like an IT problem at Mozilla. That said, I have been fleshing out some ideas about how to improve this tool.
• Started work on a little webapp, more details soon...

Published 7 January 2012

Perhaps a quiet week in terms of activity from an external point of view.

• Landed bug 471319 - undoing the last action of a textbox immediately after emptytext was displayed inserts a line feed (breaks search textbox)
• Started investigating bug 263049 - Find doesn't work in XML tree view. More investigation required.
• Started studying Tinderboxpushlog, in part to look at fixing bug 699711, but also so I can document it - current documentation is scant - and take a crack at fixing some other bugs. I aim to have the bug and docs wrapped up early next week.
• Brought my Mozilla activities up-to-date at https://developer.mozilla.org/User:Graememcc
• "We are typists first, programmers second" - put some practise into learning touch-typing, to improve productivity

Published 13 December 2011

This week, I turned my life upside-down.

I studied Computing Science at university. However, I never moved in to the computing industry post-graduation, and went another path. This never fully satisfied me, and I finally have taken steps to perform a career-switch.

Meanwhile, since the end of 2007, I've been sneaking some patches in to Mozilla Firefox. Due to time pressures, I've only ever been able to contribute fairly humble patches. I always longed to do more.

Today, I sent the following email to various Mozilla people.