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 :/
