> I think we have a handle on this now. All changes are put on Jira for > review and are not committed until there is at least one +1 from a > reviewer. (I personally prefer post-commit review because manually > attaching and applying patches is tedious but we don't have enough > people following the commit log for that to work right now.)
I don't see how post-commit review could work. The fundamental issue is that with post-commit review, lack of response means the patch stays committed. For very obvious or trivial changes, that makes sense, but for anything with real meat, the bandwidth of the people qualified to review may be very limited, and a lack of response should not be read as acceptance. And then if a reviewer finds issues after other patches have been committed on top, reverting the original patch may be a big hassle. Pre-commit review on the other hand makes the social aspects of review work to the benefit of the project. If someone wants to get a change onto the trunk, then the process gives them an incentive to make the change readable, work with reviewers to make sure the change is understood, build consensus, etc. With that said it would be nice to have a low-barrier way for people (including non-committers) to publish branches so that their work is easily obtainable and testable, even pre-merge. Unfortunately the incubator svn doesn't make that very easy but perhaps something can be done short of switching to a DVCS. - R.
