2008/8/18 Aidan Skinner <[EMAIL PROTECTED]>: > 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.
I don't follow - surely we just assign the jira to the reviewer when the issue is in the "awaiting review" stage so you can immediately see who is responsible for reviewing it? Is that not the case irrespective of whether it is pre or post commit review? >> 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. This is certainly true, the developer of the code will have an incentive to get the review done asap. Although the counter to that would be that someone who was otherwise snowed under may do a less thorough review than if he could do it at a time of his choosing. But whatever the process you can come up with scenarios like that. > In any case, it doesn't sound like you have fundamental objections to > review-then-commit, just practical concerns about the tooling? Yes that is correct. I'm just concerned that we will try to adopt a process that is impractical due in the main to limitations of our toolset and it will therefore break down. RG
