geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <>
Subject Re: Request change to RTC Process
Date Tue, 20 Jun 2006 12:49:58 GMT
Ok, I understand the issue.  To be honest I took a look at Hiram's RTC request.  The time to
and apply the patches and test them was a bit onerous given the other things I was working

I think Ken's switch from CTR to RTC was to promote communication as well as improve knowledge
really do think his comment on quality was a side benefit and not the driving force) of other
   I think Greg Stein had also indicated that perhaps a review (and not a token +1) was fair.
think that would be a place to perhaps move to and if Ken perceives were back in a ditch then
he can 
tighten it back up.

I agree that communication is much better since the RTC.  Thanks to DBlevins for whacking
me in his 
response to this.  It seemed that this thread was going the wrong way but perhaps I mis read


Dain Sundstrom wrote:
> On Jun 19, 2006, at 4:28 PM, Matt Hogstrom wrote:
>> Clearly the opinion of some on the thread is they trust each other and 
>> communication has already been fine so this is just slowing them 
>> down?  Is that the summary?  I'd have to disagree that things have 
>> been fine although I'll concede that perhaps some changes to RTC may 
>> be warranted.
> I think that the model of reviewing is working and I like it.  What I 
> don't like is the requirement to physically apply every patch and run a 
> full build.  I feel that a careful read of the patch is good enough for 
> trunk and tends to spur collaboration and communication that was the 
> original intent of switching to RTC.
> For micro releases, I taking a more conservative approach may be 
> warranted, but I honestly don't see how applying a patch and building it 
> is going to find more error.  For example, the NPEs you pointed out are 
> likely to only be found by testing user applications, and when we do 
> find one a test case should be added to prevent regressions.
> -dain

View raw message