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/
