Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <44D0C082.2050307@sbcglobal.net>
Date: Wed, 02 Aug 2006 08:10:58 -0700
From: Mike Matrigali <mikem_app@sbcglobal.net>
Reply-To: mikem_app@sbcglobal.net
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: Unexplained diff in procedureInTrigger.sql for JDK 1.6
References: <44CFE41A.7070909@sun.com> <44CFE8B3.2060606@apache.org>
 <44CFE980.6050408@sun.com> <44CFEE9D.5020601@sun.com>
 <44CFF0EF.4090402@apache.org>
In-Reply-To: <44CFF0EF.4090402@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


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.