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.
As has been previously reported, m-cMerge can now handle pretty much any tree one would care to throw at it. Most of these trees are unaffected, but m-cMerge now has some more work to do for mozilla-central, -aurora, -beta, -release, and -esrN (and the equivalent comm- trees). When you give it a changeset for one of those trees, m-cMerge will calculate the correct tracking and status flags for that tree and changeset – for example, tracking-firefox18 or status-thunderbird-esr10. Later, if it finds the relevant tracking flag set, then it will set the status flag when posting to the bug, where appropriate.
Note this means m-cMerge is no longer purely client-side JS: there’s now some server-side logic to crawl the relevant repo to find the version.
So, when does m-cMerge think it appropriate? I took the view that there should be some sort of assertion of a bug fix being sent to the bug. For -aurora, -beta, -release, and -esr, this means there should be at least one comment being sent to the tracked bug. For mozilla-central and comm-central, I added the additional constraint that you must have selected to resolve the bug. (We can’t rely on that constraint for the other trees, as the patches might be backports, and thus already resolved). Additionally, the status flag must be either unset or set to ‘affected’ – m-cMerge will refuse to change the status flag if it is set to any other value.
The help text at the top of the page will be dynamically updated as you select/deselect “resolve” and “comment” checkboxes, allowing you to keep track of which bugs will have their status flag set on submission.