On Sat, Aug 16, 2008 at 10:58 PM, Robert Greig <[EMAIL PROTECTED]> wrote:
> at the best of times, and collective accountability generally results > in no accountability. Once the process is integrated into the jira > workflow (and this applies to either pre or post commit review), there > will be a name in the frame so I think it is a different case. Not for post-commit reviews, at least no better than we currently have. The good thing about pre-commit reviews in this instance is that the onus is on the person assigned the bug to get it reviewed before it goes in. With post-commit reviews there's a lot less technical pressure to get it done, and it's harder to identify who's currently responsible for reviewing it. >> All committers should follow the processes we agree here, regardless >> of their employer. One Team, One Project, One Dream. ;) > > The point is not that people follow different processes but that if > you built up a number of outstanding review items your boss can tell > you to do the reviews immediately. That requires a lot more intervention and may not scale as we build diversity, review then commit places the responsibility for getting the review done on the person doing the work and their peers, which should be much more scalable. > Yes, it will be interesting to see if svn ever manages to make the > merge support good enough to make branch/merge a feasible strategy. svk is pretty much there with this, at least from the 1/2 hour I gave it last year. In any case, it doesn't sound like you have fundamental objections to review-then-commit, just practical concerns about the tooling? - Aidan -- Apache Qpid - World Domination through Advanced Message Queueing http://cwiki.apache.org/qpid "Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt
