Mark Brouwer wrote:
I'm inclined to a Review-Then-Commit policy although a 3 days period before being able to check-in feels like a very long time in some cases, although completely understandable from the perspective to give people time to look into it. Another risk is that 'commit starvation' occurs when there are no 3 committers finding the time to look into it and as a result there won't be any 3 +1's required to be allowed to check-in the code.
I'm no doubt being socially incorrect, but... I dislike code review deadlines; code isn't correct just because a deadline passes. I also don't ever expect committers to be expert in the entire codebase, so I'm wary of accepting +1's from only those who don't really understand the code being changed. So for implementation changes I'm tempted towards having a set of gatekeepers for each component (achieved by merit), and review must have a +1 from a gatekeeper, and no vetoes within max(N days, vote by gatekeeper). - Bob