db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: Unexplained diff in procedureInTrigger.sql for JDK 1.6
Date Wed, 02 Aug 2006 17:38:30 GMT
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.


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.

View raw message