Adding Alex and Jason to comment.

Given that this issue was in a Merge-Approved-55 state for 6 weeks and that there were 3 warnings (on the bug), this is something that should have been followed up in that 6 week period (i.e. it looks like there was a process breakdown).

Having a signal (e.g. flipping Merge-Approved-55 to Merge-Review-55) that something wasn't handled would help to raise process issues like this.  It likely wouldn't require a new label, unless we want to track how frequently it happens (e.g. Hotlist-Merge-Reivew-Unmerged).

Sorry for late reply, finally getting to this as part of the great email backlog cleanup of Q1 2017.

+josafat@ since the bug in question was Chrome OS to get his thoughts.  +cmasso@ on iOS to see what process she and the iOS team follows on these bugs.

On the desktop and Android side, we use Chrome Dash to track merges across all states - you can see our instructions for triage and a sample of what that looks like here: https://docs.google.com/a/google.com/document/d/1DEi2qePmuu5_Xx38z4FvQBElHD6jxA8N65b4vZxG7Uw/edit?usp=sharing

For us, anything marked as Merge-Approved-## is labeled "Merge Pending" in the dashboard, which is triaged as follows: "These are merges that have been approved, but the developer has not yet actually performed the merge.  Please ping the bug (or ping the developer directly if more than a few days have passed) and request that the developer merge the change ASAP.  The sooner we include changes into our builds, the sooner we can detect any issues they may introduce, so please try to have all merges completed within five days."

We gate shipping a release while we have any items in the merge pending state, unless we have already reviewed them and don't think we need to block.  This is identical to how we handle release blockers in that it's a soft gate and relies on people to review prior to pushing a release.  I think we have enough training and eyes on this to ensure we're not going to miss anything in desktop and Android at this point (without putting super strict validation into our release tooling, which could introduce other issues).

Flipping the bug back to Merge-Review-## if untouched for some time is also possible, but we'd be relying on folks looking at those bugs just the same as we'd rely on folks looking at Merge-Approved-## so I don't know that sheriffbot can help here, this feels like more of an execution issue than anything.

I'd also point out the comment from the dev saying "sorry I missed the email approval" - so I think the discussions we've had re: incorporating merges into the weekly status updates, plus pointing more devs towards tools we have available (like Chrome / Chromium Dash, both of which inform developers of pending merges they need to take action on) will also help.

On iOS, it is the responsibility of the bug owner to make sure the fix gets merged into the release branch and so we don't have a "process" to track unmerged bugs. Also, testers verify that an RBS to be merged into a release branch does get merged since they test the fix on the release branch before marking the issue as verified. 

We have modified the merge-approval reminders to now (cc the merge-requester and the merge-approver) while sending the reminders (nags).

No longer on the Chrome team, e-mail me @google.com if any attention still required from me here, otherwise good luck!