+1.
On Tue, Jul 19, 2016 at 5:27 PM, Ellison Anne Williams <eawilliamsp...@gmail.com> wrote: > 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 <smar...@apache.org> 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 <t.p.elli...@gmail.com> >> 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 >> > >> > >>
