incubator-river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ronald J Mann <Ron.M...@Sun.COM>
Subject Re: development process
Date Thu, 30 Aug 2007 11:05:54 GMT
In the case of this particular package of code, despite the procedural
issues, I am strongly in favor of RTC (and I hate code reviews). Perhaps
there are two issues somewhat at odds here.  RTC for River is largely
around maintaining the correctness of the source base; it is not an
attempt to prevent the introduction of new functionality (the specs are
there for that ;), I think this is perhaps why Bob raised the spec issue
again).   Leaving the abstract pro and con arguments around RTC/CTR for
a moment, the hard reality of a distributed system like River is that
adjudicating that there has been no new introduction of a deadlock or
race conditions simply can't be automated and is very difficult to test.
History, therefore, has shown us that an extra dollup of engineering
effort up front pays tremendous dividends in terms of everyone's time
savings on the backend. 

All this comes down to a 'rapidity of change' vs. 'correctness'
argument.  Being a distributed framework, the demands for initial
correctness and the consequences for introducing subtle mistakes are far
higher than on more monolithic code.  Debugging after the fact can be
extraordinarily frustrating and quite complex for any number of
reasons.  Though prehaps this is somewhat out of the norm for Apache
projects, IMO, in this instance, it better serves the community that we
expend the extra effort to do the best we can to ensure that any change,
when introduced, as far as the experts can say, is sound.

I don't think this means that the entire collective need vote on any and
all changes prior to committing, which I agree seems idiotic.  I think
what it does mean is that any putback requires a second committers
public assent.


View raw message