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.
