In bug 1314388, I got review, but then when I pushed a new version of the patch to MozReview to address comments, the review was lost for some reason. Someone else gave r+ so I could land it, but then the r= line on the commit would have been wrong. The actual reviewer wasn't immediately around to give his review, so I wound up pushing it manually to inbound instead. I should have been able to do this via MozReview. (Yes, in this case the original bug should just have been fixed, but there will always be cases where it's clear to actual humans what the commit message should have said.) Incidentally, in this case the tree wound up breaking because of it, because I botched the m-i push in a way that would not have occurred via MozReview (including half-baked changes from another patch by mistake).
(In reply to Aryeh Gregor (:ayg) (working March 28-April 26) from comment #0) > In bug 1314388, I got review, but then when I pushed a new version of the > patch to MozReview to address comments, the review was lost for some reason. > Someone else gave r+ so I could land it, but then the r= line on the commit > would have been wrong. imho every user who provides an r+ on a patch should be present in the r= line, as they have signed-off on the change.
I agree in general, but the one who's committing should have the ability to override this in case it doesn't make sense, if they have L3 access. Although I guess you could argue that if they want to override it, it signals a bug in MozReview, and the actual bug should be fixed rather than making it easier for people work around it. In the case that motivated this bug, it was indeed only because of a different bug in MozReview that I wanted to override it. So I don't mind if you want to make this WONTFIX, I guess.