Ok, I understand the issue. To be honest I took a look at Hiram's RTC request. The time to take
and apply the patches and test them was a bit onerous given the other things I was working on.
I think Ken's switch from CTR to RTC was to promote communication as well as improve knowledge (I
really do think his comment on quality was a side benefit and not the driving force) of other areas.
I think Greg Stein had also indicated that perhaps a review (and not a token +1) was fair. I
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 it.
Cheers.
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
