On Wed, Jun 1, 2011 at 4:41 PM, Happy-melon <happy-melon(a)live.com> wrote:
+1. Pre-commit-review, post-commit-lifetime,
branching, testing, whatever;
all of the suggestions I've seen so far are IMO doomed to fail because they
do not fix the underlying problem that not enough experienced manhours are
being dedicated to Code Review for the amount of work (not the 'number of
commits', the amount of *energy* to make changes to code) in the system. A
pre-commit-review system doesn't reduce the amount of work needed to get a
feature into deployment, it just changes the nature of the process.
This is one of the reasons I tend to advocate shorter
development/review/deployment cycles. By keeping the cycle short, we can
help build up regular habits: run through some reviews every couple days. Do
a deployment update *every* week. If you don't think your code will be
working within that time, either work on it outside of trunk or break it up
into pieces that won't interfere with other code.
With a long cycle, review gets pushed aside until it's no longer habit, and
gets lost.
-- brion