Mozilla recently announced that we are planning to de-commission irc.mozilla.org in favour
of a yet to be determined solution. As a long time user and supporter of IRC, this decision causes
me some melancholy, but I 100% believe that it is the right call. Moreover, having had an inside
glimpse at the process to replace it, I’m supremely confident whatever is chosen will be the best
option for Mozilla’s needs.
I’m not here to explain why deprecating IRC is a good idea. Otherpeople have
already done so much more eloquently than I ever could have. I’m also not here to push for a
specific replacement. Arguing over chat applications is like arguing over editors or version
control. Yes, there are real and important differences from one application to the next, but if
there’s one thing we’re spoiled for in 2019 it’s chat applications. Besides, so much time has been
spent thinking about the requirements, there’s little anyone could say on the matter that
hasn’t already been considered for hours.
This post is about an unrelated, but adjacent issue. An issue that began when mozilla.slack.com
first came online, an issue that will likely persist long after irc.mozilla.org rides off into
the sunset. An issue I don’t think is brought up enough, and which I’m hoping to start some
discussion on now that communication is on everyone’s mind. I’m talking about using two
communication platforms at once. For now Slack and IRC, soon to be Slack and something else.
Mozilla uses a lot of Python. Most of our build system, CI configuration, test harnesses, command
line tooling and countless other scripts, tools or Github projects are all handled by Python. In
mozilla-central there are over 3500 Python files (excluding third party files), comprising roughly
230k lines of code. Additionally there are 462 repositories labelled with Python in the Mozilla
org on Github (though many of these are not active). That’s a lot of Python, and most of it is
With Python 2’s exaugural year well underway, it is a good time to take stock of the situation and
ask some questions. How far along has Mozilla come in the Python 3 migration? Which large work items
lie on the critical path? And do we have a plan to get to a good state in time for Python 2’s EOL on
January 1st, 2020?
It’s no secret that I’m not a fan of try syntax, it’s a topic I’ve blogged about on severaloccasions before. Today, I’m pleased to announce that there’s a real alternative now landed on
mozilla-central. It works on all platforms with mercurial and git. For those who just like to dive in:
$ mach mercurial-setup --update # only if using hg
$ mach try fuzzy
This will prompt you to install fzf. After bootstrapping is finished, you’ll enter an interface
populated with a list of all possible taskcluster tasks. Start typing and the list will be filtered
down using a fuzzy matching algorithm. I won’t go into details on how to use this tool in this blog
post, for that see:
Imagine this scenario. You’ve pushed a large series of commits to your favourite review tool
(because you are a believer in the glory of microcommits). The reviewer however has found several
problems, and worse, they are spread across all of the commits in your series. How do you fix all
the issues with minimal fuss while preserving the commit order?
I’ve previously blogged about why I believe try syntax is an antiquated development process
that should be replaced with something more modern and flexible. What follows is a series of ideas
that I’m trying to convert into a concrete plan of action to bring this about. This is not an
Intent to Implement or anything like that, but my hope is that this outline is detailed enough
that it could be used as a solid starting point by someone with enough time and motivation to
work on it.
One of the most painful aspects of a developer’s work cycle is trying to fix failures that show up
on try, but which can’t be reproduced locally. When this happens, there were really only two
options (neither of them nice):
You could spam try with print debugging. But this isn’t very powerful, and takes forever to get
You could request a loaner from releng. But this is a heavy handed process, and once you have the
loaner it is very hard to get tests up and running.
I’m pleased to announce there is now a third option, which is easy, powerful and 100% self-serve.
Rather than trying to explain it in words, here is a ~5 minute demo:
Mach is the Mozilla developer’s swiss army knife. It gathers all the important commands you’ll ever
need to run, and puts them in one convenient place. Instead of hunting down documentation, or asking
for help on irc, often a simple |mach help| is all that’s needed to get you started. Mach is great.
But lately, mach is becoming more like the Mozilla developer’s toolbox. It still has everything you
need but it weighs a ton, and it takes a good deal of rummaging around to find anything.
Frankly, a good deal of the mach commands that exist now are either poorly written, confusing to use,
or even have no business being mach commands in the first place. Why is this important? What’s wrong
with having a toolbox?
Today marks the 5 year anniversary of try syntax. For the uninitiated, try syntax is a string that
you put into your commit message which a parser then uses to determine the set of builds and
tests to run on your try push. A common try syntax might look like this:
try: -b o -p linux -u mochitest -t none
Since inception, it has been a core part of the Mozilla development workflow.
For many years it has served us well, and even today it serves us passably. But it is almost time
for try syntax to don the wooden overcoat, and this post will explain why.
I mentioned in my previous post a mercurial extension I wrote for making bookmarks easier to
manipulate. Since then it has undergone a large overhaul, and I believe it is now stable and
intuitive enough to advertise a bit more widely.
When working with bookmarks (or anonymous heads) I often wanted to operate on the
entire series of commits within the feature I was working on. I often found myself digging out
revision numbers to find the first commit in a bookmark to do things like rebasing, grafting or
diffing. This was annoying. I wanted bookmarks to work more like a git-style branch, that has a
definite start as well as an end. And I wanted to be able to easily refer to the set of commits
contained within. Enter bookbinder.