The consensus seems to be that it wouldn't hurt to give RTC for Pirk a shot and modify as necessary. Thus, let's proceed with RTC with another committer reviewing the pull request before it's merged/accepted.
On Wed, Jul 20, 2016 at 10:03 AM, Josh Elser <[email protected]> wrote: > Tim Ellison 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 >> >> > One other thing I'd mention is that I believe CTR is much better for > growing communities. RTC has a non-zero cost associated with it and many > communities I see that are RTC struggle to get the necessary reviews in > place. CTR is great that it not only let's you move faster but also > integrate new people into your community faster. The trick I haven't > figured out yet is how to make sure that contributions which should get > reviewed don't fall through the cracks :) > > I think the mindset of try something for a few months and see how you like > it is great (try out both!). As long as the strategy you choose isn't > stifling development, do what makes you all the most productive. >
