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
  • 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.

Pushlog URLs now printed when pushing to mozilla-central

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:


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:

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:


I hope you find these changes useful!

Introducing m-cMerge

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.

Continue reading