Late to the party, but I think starting with RTC, with a re-evaluation later (no more than a couple of months) makes the good sense.
On Thu, Jul 21, 2016 at 2:00 PM, Ellison Anne Williams < [email protected]> wrote: > 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. > > >
