Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <BY2PR03MB490235775646659375AFB36991C0@BY2PR03MB490.namprd03.prod.outlook.com>
References: 
 <CADY20s4cG=UCngFUCdu5P2Lp0HJoGDGwvVeHSEFOLdYNes86Zg@mail.gmail.com>
	<CABD8fLV-rCPOEQ74O3Qua-z-34S5PjgSX2qcHGEmLMfxDeEdcA@mail.gmail.com>
	<CADY20s6Y1NzKVHs7CjyW7TTDfCJPFDYODcRG1af2n_yrUuPAOg@mail.gmail.com>
	<BY2PR03MB490235775646659375AFB36991C0@BY2PR03MB490.namprd03.prod.outlook.com>
Date: Wed, 18 Nov 2015 10:31:58 +0000
Message-ID: 
 <CA+nPnMwj8gp+H2EHqQfS4ryRvbjrpLTS5v-7ZR31MjgC5DkWCg@mail.gmail.com>
Subject: Re: RTC vs CTR (was: Concerning Sentry...)
From: Stephen Connolly <stephen.alan.connolly@gmail.com>
To: "general@incubator.apache.org" <general@incubator.apache.org>
Content-Type: multipart/alternative; boundary=047d7bfd0df8f2acf00524ce26c2

--047d7bfd0df8f2acf00524ce26c2
Content-Type: text/plain; charset=UTF-8

I believe the issue here is that with CTR it is very easy to miss the 72h
lazy consensus voting (with an assumed +1 absence any votes cast) that most
CTR projects operate under... and thus it can also be very easy to miss the
fact that there are reviews going on (and I am being generous here, I
suspect that a lot of CTR commits are only reviewed within the 72h by a
blind man on a galloping horse)

If the PMC is doing its duty, then when release time comes around, if they
have not been tracking the commits, then they should not be providing a
binding +1 for the release until they have reviewed the commit delta from
the last release *at least from the point of view of ASL compliance*.

So if we look at a well established CTR project such as Maven, you do not
see many comments on individual commits... from this you might be forgiven
if you concluded that there is no review going on... and thus infer that
CTR is really C. I cannot speak for the entire Maven PMC but I can assure
you that I reviewed each and every commit in the delta between the 3.3.3
release and the 3.3.9 release from both a technical perspective and the
legal umbrella perspective (does that mean I spotted every bug, nope... no
code review can catch every bug... and it took us 6 goes to get the release
out... but there was review)

[demagogue]
Now if a project is using RTC, in my view they probably should also be
using the 72h lazy consensus rule, in which case in the absence of a -1 the
code can be committed after 72h anyway and that should not slow down a
project or hamper contribution
[/demagogue]

I suspect the real debate should be whether RTC should use lazy consensus
voting or require at least one vote cast... that would - to my mind - get
to the heart of the debate (of course that decision is the responsibility
of each project's PMC)

I suspect that Todd would find a CTR with required vote casting or revert
just as acceptable (though much more noisy in SCM tracking with all the
revert commits)

-Stephen

On 18 November 2015 at 09:16, Ross Gardler <Ross.Gardler@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:todd@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 <gstein@gmail.com> wrote:
>
> > On Wed, Nov 18, 2015 at 1:07 AM, Todd Lipcon <todd@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
>

--047d7bfd0df8f2acf00524ce26c2--