incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: RTC vs CTR (was: Concerning Sentry...)
Date Fri, 20 Nov 2015 02:49:53 GMT
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.


[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 <>

> Interesting, Todd, can you identify which of your three arguments for CTR
> are not present in RTC.
> Ross
> -----Original Message-----
> From: Todd Lipcon []
> Sent: Tuesday, November 17, 2015 11:23 PM
> To:
> Subject: Re: RTC vs CTR (was: Concerning Sentry...)
> On Tue, Nov 17, 2015 at 11:12 PM, Greg Stein <> wrote:
> > On Wed, Nov 18, 2015 at 1:07 AM, Todd Lipcon <> 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

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