Andrew Haley wrote:
But, I am actually ok with having it be disabled by default, provided
that regressions affect gcj are treated seriously: fixed in a timely
way by the person causing the regression, or, if not, letting gcj
maintainers start the patch-reversion clock.
If we make this change I'll set up an auto-tester on the compile farm
that builds gcj along with everything else. I think this would
provide a pretty reasonable compromise.
I agree. I also agree that if someone breaks Java, they should be
required to fix the problem. In fact, we could have the rule that the
Java maintainers get to revert a patch summarily based merely on the
fact that there exists a Java post-patch failure that does not occur
pre-patch. That does shift the testing burden to the Java maintainers,
but it also means that there is no risk that Java is completely hosed.
I am a huge fan of testing, but I do think that right now we're running
too much testing for not enough return. It's not that the testing is
bad, or that more testing doesn't prevent bugs; it's that the marginal
cost of bug-prevention from the Java testing seems too high to me, given
that after-the-fact auto-testing can delivery much of the same value.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713