From general-return-23896-apmail-incubator-general-archive=incubator.apache.org@incubator.apache.org Fri Nov 13 00:44:19 2009
Return-Path:
Delivered-To: apmail-incubator-general-archive@www.apache.org
Received: (qmail 77939 invoked from network); 13 Nov 2009 00:44:18 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
by minotaur.apache.org with SMTP; 13 Nov 2009 00:44:18 -0000
Received: (qmail 62500 invoked by uid 500); 13 Nov 2009 00:44:16 -0000
Delivered-To: apmail-incubator-general-archive@incubator.apache.org
Received: (qmail 62322 invoked by uid 500); 13 Nov 2009 00:44:16 -0000
Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: general@incubator.apache.org
Delivered-To: mailing list general@incubator.apache.org
Received: (qmail 62248 invoked by uid 99); 13 Nov 2009 00:44:16 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Nov 2009 00:44:16 +0000
X-ASF-Spam-Status: No, hits=-3.0 required=5.0
tests=AWL,BAYES_00
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of gstein@gmail.com designates 209.85.216.175 as permitted sender)
Received: from [209.85.216.175] (HELO mail-px0-f175.google.com) (209.85.216.175)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Nov 2009 00:44:13 +0000
Received: by pxi5 with SMTP id 5so1933974pxi.12
for ; Thu, 12 Nov 2009 16:43:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:received:in-reply-to:references
:date:message-id:subject:from:to:content-type;
bh=2IOL5U9cAJV10NuHNCmPFzQFnCeSkwiPhNGKuZohi8I=;
b=tkv3Ei9RavOyzhs8fHkfz0XDVY3Xsjqv538uL0PU53LGoS3H+fVlRp9zct+ZYAMwT6
OSgpd4wtXyvXC0XMKvcg/BHIUGIuzY3a7aWMjVAi/o9udWzFx/TSOHLySZOs7mDk1rK9
MvCAwqaJjVZMP55z+95RhgLWU+DonydlcNNdY=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type;
b=EDUOq62MW46jd8D1P48ZlA7odH1cESPEpDWHeXuktwgthocs2qpM5GrdyAdJLLRQBi
mHrnzAs+W9XCwxZ9/tvryTMfyzHEdXKCwFren29LmiNpc0dv9GmUvu2UnKux5uxAIVYx
2sTG04fhOustcLqU2+vavS1zKViIbADNZcFg4=
MIME-Version: 1.0
Received: by 10.141.40.12 with SMTP id s12mr206102rvj.235.1258073032634; Thu,
12 Nov 2009 16:43:52 -0800 (PST)
In-Reply-To:
References:
<6cca3db30911111916o69a9557ar7ad4b3eea2f0d9de@mail.gmail.com>
Date: Thu, 12 Nov 2009 19:43:52 -0500
Message-ID: <6cca3db30911121643r4459197ftb6273e58e753c22e@mail.gmail.com>
Subject: Re: Review-Then-Commit
From: Greg Stein
To: general@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Yup. We have all had different experiences, and I certainly
acknowledge it is possible to have a successful RTC model in place.
The real problem is that there is always a success story for any
position. "See? It works here." And there are *so* many factors that
go into that success, beyond the simple tradeoff of CTR vs RTC. So it
is very difficult to objectively compare/contrast models.
We can sit around and throw out our own experiences, but those won't
necessarily apply to Cassandra.
Personally, I'm suspect of any RTC here at the ASF. In this specific
case, it sounds like more committers and a return to CTR could be
good. The 99% commit statistic (no matter *how* you want to break down
the patch-from-others) is worrying. Why aren't other committers
present and participating in that patch application? (or their own
work)
btw, if a community is not running smoothly, then referring people to
git-scm is totally the wrong solution: fix the community, rather than
sending people off to their own corners with their own branches, all
working independently rather than together. My biggest problem with
Git isn't the tech (which is great!), but the social aspects of a
default workflow that stresses individualism rather than cooperation.
Cheers,
-g
On Thu, Nov 12, 2009 at 17:46, Aidan Skinner wrote:
> On Thu, Nov 12, 2009 at 3:16 AM, Greg Stein wrote:
>
>> Not a "strong opinion", but I think that RTC hampers the free-flow of
>> ideas, experimentation, evolution, and creativity. It is a damper on
>> expressivity. You maneuver bureaucracy to get a change in. CTR is
>> about making a change and discussing it. But you get *forward
>> progress*.
>
> I think this entirely depends on how quickly you get an R. I've worked
> for $BIGCOs that do CTR and have really stifling cultures and
> $SPUNKYSTARTUPs that do RTC and have huge forward momentum. Momentum
> which is more sustainable because the explicit review means at least
> one other person knows what it is that you're doing so there's some
> instant knowledge sharing to reduce the risk of blind alleys and the
> bus factor.
>
>> I also feel that RTC will tend towards *exclusivity* rather than the
>> Apache ideal of *inclusivity*. That initial review is a social and
>> mental burden for new committers. People are afraid enough of
>> submitting patches and trying to join into a development community,
>> without making them run through a front-loaded process.
>
> I'd flip this around and look at it from the PoV of a
> not-yet-committer. RTC means everybody goes through basically the same
> process - (raise jira), hack, submit patch, patch gets reviewed, patch
> gets committed regardless of whether they have a commit bit or not.
>
> CTR means there is a qualitative difference in workflows between
> committers and non-committers.
>
>> I've participated in both styles of development. RTC is *stifling*. I
>> would never want to see that in any Apache community for its routine
>> development (branch releases are another matter).
>
> I'm sorry you found it that way, I don't think it has to be that way though. :/
>
>> My opinion is that it is very unfortunate that Cassandra feels that it
>> cannot trust its developers with a CTR model, and pushes RTC as its
>> methodology. The group-mind smashes down the creativity of the
>> individual, excited, free-thinking contributor.
>
> I think that sort of group mentality is problematic regardless of
> review model, it's perhaps a bit more commonly found in RTC but I
> don't think it's inherent to the system (you can insert your own Monty
> Python reference here if you want).
>
> The main benefit I've always found for RTC (beside being slightly
> flatter, as outlined above), is that it means that the review actually
> happens and can be seen to have happened. CTR often falls by the
> wayside, even with tooling. For Qpid 0.5 we used Jira workflow to try
> and support this and still ended up with something like 50 jiras in
> "ready to review" state. While it's possible that somebody read the
> code and couldn't be bothered to click the button, I think it's much
> more likely that they're basically unreviewed. There's also a number
> of Jiras that are essentially review comments that have been kicking
> around for ages.
>
> A number of large, venerable projects run with RTC for a number of
> reasons. I know a lot of people dislike it due to prior bad
> experience, that it stifles them, holds up progress etc. To them I say
> http://git-scm.com ;)
>
> - Aidan
> --
> Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org
> "A witty saying proves nothing" - Voltaire
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org