Mailing-List: contact cassandra-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cassandra-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <4239a4320909181312ya191c9u4c6fb8b1a039c504@mail.gmail.com>
References: <4239a4320909181312ya191c9u4c6fb8b1a039c504@mail.gmail.com>
Date: Fri, 18 Sep 2009 16:34:50 -0400
Message-ID: <aa36bf910909181334k43fb35e7t288e028b268e317c@mail.gmail.com>
Subject: Re: [PROPOSAL] CTR for all non-code changes
From: Ian Holsman <ian@holsman.net>
To: cassandra-dev@incubator.apache.org
Content-Type: text/plain; charset=UTF-8

I'm happy with this
The comitters know what they are doing :-)

On 9/18/09, Paul Querna <paul@querna.org> wrote:
> Hi,
>
> I'm not a commiter (yet!) for Cassandra, but it seems that doing
> simple changes like fixing up the README requiring RTC
> (review-then-commit) is over burdensome, without providing any
> advantage to stability.
>
> For the Apache HTTP Server project, while we use RTC for all of our
> stable branches, for documentation and other non-code changes, we use
> CTR (commit-then-review).  This lets simple things like typos to
> developing large chunks of documentation happen quickly and without
> any process burdens, which has allowed the Apache HTTP Servers great
> documentation project to thrive.
>
> I am starting to believe it would be helpful if Cassandra adopted a
> similar CTR policy for non-code changes on trunk and all branches.
>
> Thoughts?
>
> Thanks,
>
> Paul
>

-- 
Sent from my mobile device