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

Reply via email to