Mark Brouwer wrote On 08/30/07 11:18,:
>Ronald J Mann wrote: > > > >>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. >> >> > >Hi Ron, does this mean that you also see value in Bob's process idea or >do you consider RTC as described at the ASF website as sufficient? > > Sorry for the delayed response...(it had nothing to do with you putting me on the spot with Bob ;-) was away on personal issues for the past few days). This is a difficult question for me. I'll start by saying that I'm not a big fan of process, I prefer common sense, unfortunately once there are a dozen or so people involved sense is rarely all that common. As a team here we have and to some extent continue to struggle with the notion of RTC vs CTR as there are times when one wishes to innovate rapidly and therefore is willing to risk more of a stability hit, whereas there are others when correctness is the primary goal. As I read the ASF rules, I think we should rule out the notion of group voting on individual code changes as far too heavy handed. Others have mentioned the quality of the the minds involved on this project, most of whom I know well and I'm perfectly happy to trust any given pair of us to do the right thing. As such, I'm content to have the notion of RTC mean that to commit a change requireds that the comment contains a reviewed by reference. In the case where a change is so trivial, dotting an i or crossing a t, I'm aware that its a pain to have to find someone to do so, but frankly a quick post to the list and it can be handled by anyone quickly. If the changes are deep and heady, its almost unimaginable to me that anyone would want to commit without at least one good pair of eyes perusing the changes first anyway. I alluded to the Sun team's own internal philosophical struggles with RTC vs CTR. I believe in the end after many years of angst and debate, we've simply come to the conclusion that the fastest most reliable path to nirvana is to RTC. I will admit, when I first joined the team I misinterpreted the use of RTC as a bit of a personal slight on my abilities. I'd urge committers not to view it as such. I think we've found that RTC can contribute positively to team building, whereas CTR, which generally occurs after problems are found, can have the opposite effect. Yes, there are times when RTC is a perfunctory operation and largely unnecessary, however in these moments, the cost of oversight is very small and goes largely unnoticed. Ongoing stability is dead critical for making any progress with this body of code and IMO, a review by a second committer prior to putback is a necessary evil. To be clear, my comments here are around changes to the underlying implementation which are presumed to have no/insignificant impact on the specs. I'm a tad confused on the who owns the spec issue, but assuming this group has the authority, full blown spec changes I believe demand that the full group vote and would certainly demand RTC as well. =Ron=
