On 17/07/16 19:31, Suneel Marthi wrote: > +1 to RTC, this is what's presently done on Flink, Mahout and few other > projects I had seen. > > Its usually a committer reviewing the patch, providing feedback, and > finally committing it. > Whether a pull request gets a +1 from another committer or not is entirely > up to the project and could be decided on a case-by-case basis. > > A complex change or design might need more reviewers while a simple change > could be good to commit without additional reviews.
By way of balance, I'll offer up the argument for CTR with tweaks... CTR has a number of advantages too across a number of different scenarios. First thing to say is that committers are usually trusted to "do the right thing", so further reviews of a committer's work are generally introduced only when additional checks-and-balances are required. Working with CTR allows the committer to just get on with it, on the understanding that numerous eyes are watching the changes and will raise any problems that they see. Of course, the code is all in version control, so where a committer has changed something that may be a problem for others, it is easy to roll files back to a point where the objection is being raised, and walk forwards again during a review / discussion. CTR allows for faster development (no need to wait for reviews) and arguably more frequent committing (no tendency to save up chunks for block review before they hit the repo). Many eyes watching small commits may be better than a nominated review of a large piece of work. That said, there is a place for RTC - and when working towards a release it is helpful to chill the codebase (no new features) and test, then freeze (no bug fixes without RTC) before making the release, to ensure stability. Regards, Tim
