groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: New Workflow…
Date Mon, 27 Apr 2015 16:44:02 GMT
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. 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 ;)

[...]
>> With that, this process is useless for the group of people where it is
>> most needed: newcomers and striving to be committers. Which means you
>> need a review before commit in any case.
> Yes. But again, are you taling about CTR or RCT ?
>>
>>> - for some critical projects, it's r-t-c (Review Then Commit). I think
>>> this is what httpd is doing. If you think that the groovy project is at
>>> risk then switch to r-t-c.
>>
>> In general it has the same time problem, only that you have to deal
>> less with broken builds, but the review time will be  there as well of
>> course, and if you have to do this for every commit, you better have
>> an not too active project or you are going to be crazy or spend a lot
>> of time. But for new contributors, this is the better way in my
>> experience.
>
> 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.

>>> FTR, I deal with pull-requests for the MINA project, and it works simply
>>> fine. I can review the code, and I can decide to apply it - or not.
>>
>> sure, I was just pointing out, that Gerrit is for me most likely no
>> replacement for github
> Most certainly. There is no magic bullet, sadly :/

The question is for what/whom we would use gerrit, if we would use it. 
Reviewing all committs? Not sure we can do that.

bye blackdrag

-- 
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/


Mime
View raw message