Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of ammulder@gmail.com designates
 64.233.162.197 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=EZmo4DOw6D69TzTFUCqUOWv/LOtIAYyvNVhqqEeQmHqiZkW+h+uVAuG/2PJpNbAaxdqfyvqT3HK/Hn9ixbPyl7u8xN7kmsfC0mcVXbcp4Fq8m4fBkkGZvsUGSbgFjuvI0TkWlHK6BsC04Dl4oJTA3KurfuYMFhC9dEnvjvI2ieQ=
Message-ID: <74e15baa0606170833o1d07cd28mde39cc2dabb364e6@mail.gmail.com>
Date: Sat, 17 Jun 2006 11:33:58 -0400
From: "Aaron Mulder" <ammulder@alumni.princeton.edu>
Sender: ammulder@gmail.com
To: dev@geronimo.apache.org, coar@apache.org
Subject: Re: Request change to RTC Process
In-Reply-To: <44941004.8070503@Golux.Com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <B0E977E8-3FE0-42F7-A39D-B8DAFE79DB67@gmail.com>
	 <44941004.8070503@Golux.Com>

On 6/17/06, Rodent of Unusual Size <Ken.Coar@golux.com> wrote:
> If that means things languish for weeks or months, then
> that's what it means.

I don't think this is a good idea.

The RTC process (as Ken is describing it) has a number of side effects:

 - Eliminates trust.  I know say, David J has a lot of experience with
say, connectors, and if he puts a patch in that area, I think I can
read his summary and trust that he's implemented it sensibly.  But now
that doesn't count, I have to review it line by line?  I think it
should be up to me which patches I trust and which patches want to
review in detail.

 - Favors full-time open source developers over free-time
contributors.  I don't have enough time to work on the work *I* want
to do in my spare time, much less get a clean tree to apply, test, and
review everyone else's patches

 - Favors bug fixes over innovation.  Anything that's characterized as
a bug fix gets a free pass.  Also, it's unmanageable to review large
changes in detail, so only small changes have any good change of being
applied in a timely fashion.

 - Encourages "cliques".  Who am I going to ask to give me a quick +1?

Now, you can argue in favor of this for a maintenance / bug-fix
release like 1.1.1, where the main goal is to improve quality and
extra eyes on every line may help avoid bugs.  But it's a significant
obstacle for a feature release like 1.2.  Additionally, it doesn't
help the stated goal of improving communication.  If everyone wants to
see what I'm doing, and I post it to a Jira and announce it, they can
see.  If they want to review in detail, they can.  If they can review
the description and perhaps give it a cursory glance and give it a +1,
that's achieved the goal of making sure they're aware of things going
on in the project.  If you say they can't +1 it without an exhaustive
review and test, that doesn't add to the quality or quantity of
communication.  It only adds obstacles to delivering the features
desired for the 1.2 release.

Thanks,
    Aaron