Todd: as Ross notes, your three points about code reviews in a CTR project are quite valid, and match accepted engineering practices.
What I haven't seen is an explanation why a committer must be treated the same as a drive-by. Both are subject to requiring "permission"[1] to make even the simplest of changes under RTC. Even worse, from else-thread, it sounds like under your control scheme, you don't even allow the committer to apply their own change [after review]. A committer can give a binding +1 to somebody else's work. But they aren't trusted to give that to their own work. Just like a drive-by contributor can't be trusted. -g [1] thanks to Upayavira for capturing the essence of RTC: it is a "permission" mechanism for control. On Wed, Nov 18, 2015 at 3:16 AM, Ross Gardler <ross.gard...@microsoft.com> wrote: > Interesting, Todd, can you identify which of your three arguments for CTR > are not present in RTC. > > Ross > > -----Original Message----- > From: Todd Lipcon [mailto:t...@cloudera.com] > Sent: Tuesday, November 17, 2015 11:23 PM > To: general@incubator.apache.org > Subject: Re: RTC vs CTR (was: Concerning Sentry...) > > On Tue, Nov 17, 2015 at 11:12 PM, Greg Stein <gst...@gmail.com> wrote: > > > On Wed, Nov 18, 2015 at 1:07 AM, Todd Lipcon <t...@apache.org> wrote: > > >... > > > > > I think it's a _plus_ that contributors and committers contribute > > > code in the same way -- it's more of a level playing field for new > > > people contributing to the project. > > > > > > > "level playing field"?? seriously?? > > > > I find no logical or valid reasoning to drag committers down to the > > same level as drive-by contributors. > > > > I gave the logical and valid reasoning in previous posts in this thread: > 1) no matter how seasoned a committer you are, you might make mistakes > which are easily caught in code review > 2) no matter how good you are at coding, your code might not make sense to > a second pair of eyes, who can ask you to improve comments or docs > 3) no matter if your code is perfect, the act of another person reading > your code builds shared ownership over the code, thus alleviating > bus-factor issues and improving the general feeling of a cohesive community > developing a single project instead of a loose coalition of people with > their own fiefdoms. > > I believe this to be generally accepted in the software engineering > community. I don't know practices at every company, but I know at least > that most of the well-regarded technology companies I've met with have some > form of pre-commit review, and certainly many highly adopted open source > projects as well (especially in infrastructure software). > > Either a high percentage of the world does this for "no logical or valid > reason" or this is just a matter of opinion, and like I said, we can agree > to disagree. > > -Todd >
