On Tue, Nov 17, 2015 at 8:50 AM, Steve Loughran <ste...@hortonworks.com> wrote: ... snipped...
> > But at the same time, RTC dissuades me from doing the minor stuff, because > the effort to submit a patch to correct a spelling error in a comment is so > high. I think it can endanger code quality. > > There's also the fact that even those bigger patches I may do, will need > to be reviewed before commit —and there's a backlog on the Hadoop codebase > which includes a lot of mine. Other people are as lax about reviewing those > patches as I (sadly) am about reviewing patches from people other than me. > It takes effort and time, and if you are working on something full time, > where that means evening and weekends as well as daytime, then its easy to > neglect things. > Big +1. This is one of the reasons that I'm a big fan of gerrit for contributions, and why a lot of people are big fans of github pull requests. With the "post patch on JIRA (or mailing list)" workflow, the committer, in order to review, has to download the patch, apply it, look at a diff with more context, rebuild the project, type up notes, and paste them back into the JIRA. If it's a simple patch and there are no notes, the committer still has to manually apply it, write a commit message, and push from their own box -- typically at least running a build in between to make sure they didn't somehow mess up the patch application or commit their own WIP junk from their repository. This makes it at least a 5-10 minute process (often longer if my local repository is in bad shape) to commit a trivial change contributed by a new contributor. Compare to gerrit: I see a patch up for review. It shows me the diff in context along with the author's commit message. For a trivial patch, I can review it in 30 seconds. When it's good to go, I hit a "Submit" button and the rest of the workflow is taken care of. End-to-end time less than a minute. It might seem petty, but I've witnessed my own behavior in these two different workflows. On Hadoop, I rarely go through the patch queue, because I know that it's going to be a big pain to review even trivial changes. There's a vicious cycle, because when changes aren't reviewed quickly, they fall out of date, and then become harder to review, take more effort from contributors to rebase, etc. On other projects that use gerrit, I rarely see a mergeable trivial patch last longer than a couple hours before someone clicks the necessary buttons to merge it. This may all seem orthogonal to RTC vs CTR, but I think my point is this: the actual review workflow strongly affects the rate of progress in RTC projects. -Todd -- Todd Lipcon Software Engineer, Cloudera
