[trustable-software] Best-practice for Reviews: Review-Then-Commit vs Commit-then-Review

[Paul Sherwood]

Hi folks,
while not quite as exciting as Edmund's 'there are never any 
requirements' bombshell, I've been directed to some research [1] and [2] 
about how Apache evolved its review process and found it extremely 
interesting.

The TL; DR is that review friction led them to two different paths to 
mainline:
- CTR: 'core developers' can commit direct to mainline if they are 
confident in their proposed changes
- RTC: all changes from other developers get reviewed first, along with 
'core developers' more complex/risky changes

This seems to clear up a little mystery that had been bothering me; when 
a project starts from scratch, people rarely bother with reviews and 
arguably it's not really a good use of time. Reviews start to matter at 
the point where breakages will have repercussions. But by the time that 
happens, there's already a set of 'core developers' who know the 
software way better than most, and end up disproportionately loadsd with 
reviews of less qualified contributors' work. This two-path approach 
seems to address both underlying problems.

br
Paul

[1] 
https://www.computer.org/csdl/proceedings/icse/2008/4486/00/04814165.pdf
[2] http://www.inf.ed.ac.uk/teaching/courses/rtse/Lectures/rigby.pdf