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.

m-cMerge

m-cMerge is the fruit of that labour. It lives at https://paas.allizom.org/bugherder/, with the source available at https://bitbucket.org/graememcc/m-cmerge. Designed to be used immediately following a merge to mozilla-central, it will load the specified pushlog, and attempt to work out what fixes made it, what got backed out, and separate out merge changesets, no-bug changesets and other noise. One can then manually review, correct any misdetections, and hit submit to have the relevant changes made to Bugzilla.

To begin, enter the changeset hash of the merge:

m-cMerge gets busy, loading the pushlog, categorising the changesets, and loading the relevant bug data. The results will be split into 5 categories:

• Fixes (pushes that stuck!)
• Pushes backed out
• Backouts of things not in this merge
• Merge changesets
• Other changesets

If a particular merge does not contain any pushes of a particular type, it will be omitted.

The text at the top calls out various special cases, for example bugs with "leave open" in the whiteboard (which default to comment without resolving), and security bugs. Note that you cannot resolve or comment in security bugs in m-cMerge - I feel those are best altered by human hands. Underneath, you will find the relevant pushes, ordered from newest first, to mirror the pushlog, with any bugs that m-cMerge believes should be commented immediately below.

Most of the controls should hopefully be self-explanatory. If the "Comment:" checkbox is checked, a comment will be posted in the bug. If the "Resolve:"  flag is checked, the bug will be marked as RESOLVED FIXED. Additionally, when resolving, one can change the target milestone, by selecting from the drop-down menu. Where possible, m-cMerge will suggest a sensible value for the target milestone. You cannot set the target milestone when only commenting; if the bug is not being resolved at this point, I do not believe you can make any claims about the milestone.

Comments

Click "View/hide comment" to view the suggested comment for a particular changeset, and verify it is correct. You can amend the comment as necessary.

If there are a series of changesets all associated with the same bug, i.e. you have pushes of the form "Bug XXX - Part 1: fix something", "Bug XXX - Part 2: fix something else" and so on, the comments will be merged into a single comment on submission, with the comment for the oldest changeset first.

The comment checkbox works on a per changeset basis: if you have 3 changesets associated with one bug, and deselect the comment option on one changeset, the other two will still be commented unless you instruct otherwise. In contrast, the resolve checkbox works on a per-bug basis, affecting all instances of that bug.

Mis-detected bugs

Only 90% of the way, remember? Due to the wide variety of commit messages, m-cMerge will sometimes get it wrong, particularly when a commit message references multiple bugs. Next to each bug are "remove" and "change" buttons, to allow you to disassociate a bug, or correct which bug will be resolved.

Additionally, the "add bug" button, does the obvious thing, allowing you to send a comment about a particular changeset to multiple bugs.

Submitting

When you've reviewed all the changes, scroll to the bottom to find your friendly neighbourhood "submit" button. You will then be asked to supply your Bugzilla credentials, which will then be used to communicate with the Bugzilla REST API over https, and make the specified changes.

Backouts

The creativity in commit messages reaches whole new levels when it gets to backouts (pro-tip: flick to the pushes backed out section to check for any misdetections before submitting any fixes). Where possible, m-cMerge will associate the pushes backed out with the thing that backed them out.

Both backouts and the pushes backed out default to neither commenting or resolving, but that can of course be changed via the controls provided. As seen in the picture above, m-cMerge can cope with a push that backs out multiple other pushes. Indeed, it should cope with ranged backouts e.g. 'backout aaabbbcccddd-111222333444' or 'backout aaabbbcccddd through 111222333444' , and 'backout aaabbbcccddd : 111222333444'. When you messy pups really hose the tree, it can deal with 'revert tree to changeset aaabbbcccddd'. For normal backouts, it understands 'revert' is a synonym for 'backout'.

m-cMerge's backout detection really is only as good as the commit messages. I would encourage the use of changeset hashes in the backout commit message to specify exactly what was removed.

Summary

After all the individual sections, m-cMerge provides a handy summary of the damage unleashed on Bugzilla.

If it looks like you forgot to submit, m-cMerge will issue a warning.

It will also nag you about your part of the deal: resolving security bugs.

Patches welcome

I hope this is enough to be useful to inbound sheriffs. It could be prettier though. I'm not entirely sure how best to present the information in the summary; the dialogs use an off-the-shelf jQuery theme, and don't tie in with the rest of the site. The "loading" message should stay centered on the screen when you scroll, and I thought I should just have been able to set "position: fixed;" on it - instead it defeated me until the bitter end. And of course, with all your prodding and poking, you'll likely find other bugs: on the other hand, you'll now have lots of free time to fix them, now that you're not resolving bugs all day!