Thanks for the tips, Mike. I think I'd like to go for adjusting the
output rather than comment out the statement or pull the test, since it
is specific to JDK 1.6.
David
Mike Matrigali wrote:
Daniel John Debrunner wrote:
David Van Couvering wrote:
Now that I think of it further, I suspect it is not good practice to
hold a test hostage waiting for this bug to be fixed, and I should
probably add a jdk16-specific master file for procedureInTrigger.sql.
I can point the reader of the bug to this master file as a guide to
reproducing the problem...
Any thoughts? Otherwise I'll go ahead and do that...
Little nervous. Especially as your comment says "so at least derbyall
can pass". With derbyall "passing" a release could go ahead, having
derbyall failing might hold up a release, but I can't see anyone making
DERBY-1629 blocker or critical. Maybe the fact it is marked as a
regression is enough.
Is there any harm in having this test continue fail due to a real bug?
In general I think it is a bad idea to leave "expected" diffs in the
regression suite. I think it causes unnecessary work for all the
developers trying to figure expected vs. "real" diffs. I think that
filing a bug and marking it a regression should be enough.
I am not as clear on the right way to "make it pass". I am
uncomfortable with just creating new master. In the past we have
sometimes just removed the test from the suite until the bug is
fixed - which means less testing. Sometimes we have just removed
the offending statement until the bug is fixed. And other times
with the canon based tests we have added comments to the test
output itself saying something like "the next few lines are wrong
due to the DERBY-xxx" and then updated that master - that has the
benefit of making it very clear when the bug is fixed and a new
diff appears why it is happening.
