incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: Review-Then-Commit
Date Fri, 13 Nov 2009 00:43:52 GMT
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 <aidan.skinner@gmail.com> wrote:
> On Thu, Nov 12, 2009 at 3:16 AM, Greg Stein <gstein@gmail.com> 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


Mime
View raw message