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 ( <[email protected]> _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
