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 02:27:55 GMT
The harm is that each developer has to sift through a diff for a known 
bug.  If we all did this then we would have a stack of diffs and we'd 
have to do pattern recognition to know if our change caused a regression 
or not.  That has me concerned...  That's why I thought I'd log the bug, 
since it's not a major issue, and note that a canon file is masking the 
bug for now.

I think there are a whole class of master file outputs that are there 
because of bugs.  I think I even fixed a bug for 10.1.3 that you 
reported which had its output encoded in a master file.


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?
> Dan.

View raw message