It seems that we could give RTC a shot, with one reviewer posting a +1 (or equivalent) comment on a pull request before it is accepted, and switch back to CTR if RTC became too burdensome.
It seems healthy to foster explicit accountability and to give others the opportunity to discuss changes before they are committed. This may become too much for small commits, especially to the website, but we can always adopt CTR (or a combination of the two for certain situations). Thoughts? Thanks! On Mon, Jul 18, 2016 at 9:22 AM, Suneel Marthi <[email protected]> wrote: > 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 > > > > >
