How to Eat an Elephant

This is about levels of change. It's partly about hg.mozilla.org vs GitHub (or BitBucket). But it's more about our devt/review/commit process.

Moz-central demands patches that solve significant issues, and it's probably right in wanting this, but this bite size comes with problems.

There are 3 levels of change worth discussing:

1. The detail level we're used to working at: 'Added foo', 'Renamed foo to bar', etc. If working in a small team, this is probably the level we would commit at. At this level it's easy to understand the intent behind each change.
2. The review level which is an ideal chunk for someone to review. You probably don't want to review every new commit as it's done, but on the other hand, you don't want to be told that you made a mistake weeks ago and need to redo lots of work. So ideally this happens on something like a daily basis. It's the scale that pull requests were designed for.
3. The patch level which mozilla-central is used to, and which is ideal for commit. The work is 'done' and useful for a much wider audience. When a bug is fixed we can extract a patch to be committed, like this one for bug 684958.

The problem with the Mozilla process is that steps 1 and 2 don't exist at all. The benefits to the existence of more detailed change levels are:

• Review is faster and deeper. You can review this pull request far better than a conventional patch because you can see what I'm intending by each change - you don't need to reverse engineer the intent and mentally hold together all the bits of mashed together bits of intent.
• Smaller changes are easier. Our current process prevents us from clearing up small things that are not directly related to the bug in hand. We can (for example) entertain the thought of variable renaming because it won't confuse the patch. There may be other reasons not to go crazy with this, but at least the process won't be one.
• Progress is visible. Because we can share to a smaller team before we're done, everyone gets to see what's happening. There is a feeling of momentum - progress is the norm. Just like a 6-week cycle is better than an 18-month cycle, a daily commit/pull cycle is better than a weekly patch/review cycle.

In effect we're using GitHub as a tool to develop patches for Firefox, rather than to develop Firefox itself. In some ways I mean this literally.

There are probably reasons why the detail of what works for GCLI might not exactly work in other places, but I'm willing to bet that these ideas could be adapted to be of more general use.

Fundamentally we solve big problems by breaking them down into smaller steps.

I can eat an elephant, but not by opening really wide.