thanks Tim, this is a great perspective indeed, like the way u put it. On Mon, Jul 18, 2016 at 6:50 AM, Tim Ellison <[email protected]> wrote:
> 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 > >
