incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd Lipcon <>
Subject Re: RTC vs CTR (was: Concerning Sentry...)
Date Tue, 17 Nov 2015 17:06:42 GMT
On Tue, Nov 17, 2015 at 8:50 AM, Steve Loughran <>
... 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

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

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

Todd Lipcon
Software Engineer, Cloudera

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message