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.
David
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.
