Talk:Gerrit/Code review

"Reversions themselves are always "ok"."
What if person A makes rX, which fixes bug P, and then person B reverts rX in rY because he thought it added bug Q, which was actually caused by something else. Since rY re-introduces bug P, can't it be marked fixme? Aaron 23:43, 15 November 2010 (UTC)


 * We mark reversions "ok" because it's OK to be cautious. The reviewer may have reintroduced the bug, but at least the situation is no worse than it was in the previous release. The onus is on the developer to convince the reviewer that their changes are worth having. The change that introduced the bug in the first place can be set from "resolved" back to "fixme", and the relevant bug reopened, while the developer is working on a solution that will make everyone happy. If it proves that the revert was a mistake, then the developer (or someone else) can reapply the change, once consensus is established that that's the right thing to do. -- Tim Starling 05:16, 3 February 2011 (UTC)

Inspected and tested
Hallo. What is exactly the meaning of "inspected" and "tested" in code review?

If i have to guess, "inspected" = "i read the code" and "tested" = "i tried to run the code". And in both cases it also means "i think that it's fine, but not sure enough to mark as OK".

Did i understand correctly? --Amir E. Aharoni 00:26, 18 October 2011 (UTC)
 * Yes! Sumana Harihareswara, Wikimedia Foundation Volunteer Development Coordinator (talk) 18:37, 17 February 2012 (UTC)

To add re Gerrit
-2 does not veto a change or prevent a merge going through. It's a strong disapproval. But another project owner can still come along, add a +2, and merge. The only way to actually cancel a commit and take it out of the merge queue is to click Abandon Change. Sumana Harihareswara, Wikimedia Foundation Volunteer Development Coordinator (talk) 23:36, 27 February 2012 (UTC)