> On Nov 25, 2015, at 3:22 PM, Todd Lipcon <t...@apache.org> wrote: > > Isn't it an issue of scalability? With pre-commit code reviews, typically > the uploader of the code will pick out one or two people to review the code > who know the area well. Or, if no one is picked by the submitter of the > patch, the committers will organically end up deciding who is to review the > code, at which point that reviewer ends up being a sort of shepherd for the > patch, sticking with the contributor through multiple revs until it's ready > for commit. > > With post-commit review, do you expect to watch the mailing list and review > every patch that comes in? In a project like Hadoop, that's not feasible -- > we've had ~35,000 lines of code changed in the last month in 267 patches. > If everyone tries to review every patch post-commit, you end up with n^2 > work as the community grows.
Maven is a large project with a decent number of committers. People naturally pick their areas and review the code in their areas of interest because it is important to them. Maven also has a large suite of integration tests for the core and a group of people who are interested in that. Each of the Maven plugins has a group of people who gravitate towards them. No one really has to assign anything. With Log4j we have one individual who commits a lot but most of his commits are to change variable names, fix javadoc bugs, and other general code cleanup tasks. I will look at the commit log message and won’t review those directly because I know that is what he is doing. But when he makes a code change with a Jira issue tag I will do my best to review that. That won’t be reflected on the dev list because I only comment when I find something that needs to be updated. The major difference I see between the CTR projects and the RTC projects is that the RTC projects mandate that everything has to go through the review-then-commit process. CTR projects a) allow portions of the project to be RTC or b) allow committers to choose to use RTC for specific commits. It is almost like we are dealing with the difference between the GPL, where the code is supposedly free, and non-copyleft licenses where the user is free. Both can get the job done but both come with a different set of benefits and costs. Much as I don’t care to participate in GPL projects I also don’t care to participate in pure RTC projects as both restrict me in ways I very much dislike, Ralph --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
