On 2/28/11 1:08 PM, Ashar Voultoiz wrote:
It would be great if other developers can tag their
commits with the
same tags and we could start shy developers in reviewing more.
In general I don't think developers should be deciding that their own
commits are easy or hard to review. One line changes can sometimes take
forever to verify.
To me this feels like the wrong solution to this problem. People who
review code shouldn't be afraid of commits.
This might be an unworkable solution for Wikimedia at present, but I
find pre-commit code review tends to align everyone's goals better.
With post-commit review, the developer can commit big chunks of
difficult-to-understand code, and the pain of reviewing it is all on the
reviewer, and people procrastinate this.
But if the developer can't even commit without a review, like magic,
they find ways to break up their changes into small, easy-to-understand,
well-documented changes.
I'm a huge fan of pre-commit review. I started to investigate this
months ago, before I really understood our Code Review tool. It seemed
like it would be too difficult to integrate pre-commit review with our
current toolchain.
However, if we ever move to git, maybe we should also think about
pre-commit review. (In the git world, that would mean review before
merging with the production repo, but basically the same idea).
--
Neil Kandalgaonkar ( <neilk(a)wikimedia.org>