> -----Original Message----- > From: r...@databricks.com [mailto:r...@databricks.com] On Behalf Of > Reynold Xin > Sent: Sunday, November 22, 2015 22:33 > To: general@incubator.apache.org > Subject: Re: RTC vs CTR (was: Concerning Sentry...) > [ ... ] [orcmid] > 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. [ ... ] [orcmid] 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: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
