incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: RTC vs CTR (was: Concerning Sentry...)
Date Mon, 23 Nov 2015 12:34:26 GMT

> -----Original Message-----
> From: [] On Behalf Of
> Reynold Xin
> Sent: Sunday, November 22, 2015 22:33
> To:
> Subject: Re: RTC vs CTR (was: Concerning Sentry...)
[ ... ]
> Committers are required to use JIRA, github, and follow many other
> processes that "drive-by" should follow. I don't see why "code review"
> is
> different from filing JIRA tickets. In most RTC projects, committers do
> have more rights -- a committer can review somebody else's patch and
> commit
> it.
[ ... ]
Caught my eye.  

In the one place where I see RTC, when it is a committer who proposes RTC, it is that committer
who will ultimately make any commit.  

Admittedly, this is in a case where C[TR] is available.  

Even on a project where RTC is the norm, why would not the original committer be allowed to
commit, based on whatever adjustments review requires?  (I am not equating this with lazy
consensus, although that might be an individual case.)

A formal RTC arrangement as I see described strikes me as similar to situations where (senior)
professional engineers are responsible for reviewing and approving the work of others.  I
can understand the commitment to quality and accountability that represents, along with the
premiums for malpractice insurance that go with it.  (I assume that pair-programming is not
so formal and the original committer is as likely to do the commit as the buddy.)

I can see the code being produced being under an open-source license too. I am failing to
grasp how formal RTC can fit with the ASF drive for flat, non-authoritarian structures, though.
 I suppose I don't have to understand it, it being unlikely that I would ever be involved
in such an arrangement at the ASF.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message