groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: New Workflow…
Date Mon, 27 Apr 2015 17:45:22 GMT
Le 27/04/15 18:44, Jochen Theodorou a écrit :
> Am 27.04.2015 15:51, schrieb Emmanuel Lécharny:
> [...]
>> No, you can have someone who is not a committer, who send a pull
>> request, which is reviewed by a committer. Actually, CTR works this way
>> for external contributiions, and it's not really a huge pain.
> I don't perceive that as CTR, but well, we seem to have different
> understandings here. 
To be clear (or to clarify what I mean) :
- ctr and rct are both way to process an update *for committers*. For
contributors, a review is necessary, of course. I may have made things
blurry in my previous mails.

> Sure, you do a pull request with a commit. But that commit usually
> does not go into the normal repository - at least on github, which is
> the only platform I know supporting something like a pull request. But
> the traditional git-DCVS way works similar. I do local changes and
> make them available to someone higher in the chain, who will then pull
> them from me or not. Still this is more a review first, then merge
> (commit to higher repository) process to me, not one where I commit to
> a repository I don't "own" first.
>> For RCT, that would again be more costly : not only you will need a
>> committer to review the PR? but you would also need at least anouther
>> committer to do the same.
> don't even know what RCT stands for ;)
Review-Then-Commit as opposed to Commit-Then-Review.

Basically, when a non-committer propose a patch, a committer will RTC,
and for most apache project, when a committer has a patch, then it's a
CTR except for some critical projects, where another committer has to
validate the patch (thius this is a RTC)

>> Indeed. And to save you time, better accept a contributor as a committer
>> quickly than waiting for 100 PR from him ! In my experience, it's easier
>> to mitigate a bad committer (someone who break the build with their
>> commits) than to spend time reviewing every contribution for ever. At
>> some point, you have to trust active contributors to be good
>> committers !
> I still review all commits to most of groovy, but only if I have the
> time, if I am curious about the solution or the general approach and
> there was not enough communication about this before hand, or if the
> commit is possibly doing changes I have to know of for my current
> work. This has nothing to do with not trusting. Some parts, like the
> AST representation of generics for example, are so bad in Groovy, that
> anything, that does a bit more complex logic needs a second or third
> look. Actually I am usually happy if people review my code and show me
> mistakes I made or ask why I did this and that. For me that is part of
> ensuring code quality.

I'm totally with you on that. Sadly, the premise : "but only if I have
the time" applies so frequently that at some point, the project is
growing and moving forward without reviews :/

View raw message