db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Bouschen <mbo.t...@spree.de>
Subject Re: Test Case Challenge Process
Date Tue, 03 Oct 2006 12:48:09 GMT
Hi Craig,

I agree with the proposed process handling test case challenges.

I looked at the new branch 2.0.1 and would like to propose updates to 
the project.xml files:
- Update the currentVersion entry to 2.0.1 in the project.xml files of 
api20, core20, enhancer20, and tck20.
- Update the JPOX dependency to 1.1.1. I tried version 1.1.2, but this 
version fails to run the 2.0.1 version of test class FetchPlanInterface. 
The test class has been fixed in the trunk (see 
http://issues.apache.org/jira/browse/JDO-402) and JPOX 1.1.2 
accommodates this change. So I think it is ok to use version JPOX 1.1.1 
for the 2.0.1 branch.
- Update the Derby dependency to I propose to update the Derby 
dependency in the trunk version, too.

I attached a patch for review. Please have a look.

Regards Michael
> There are currently 14 challenges filed by BEA that need to be 
> resolved within 15 working days of receipt.
> From the TCK RunRules document that is part of the official JSR 
> release, the first level TCK Challenge process includes the following:
> <spec>
> If any test does not pass on the JDO implementation under test, this 
> may be due to an error in the implementation or in the TCK test. If 
> you believe that the failure is due to an error in the TCK test, you 
> may challenge the test. To do so, send email to: jdo-dev@db.apache.org 
> <mailto:jdo-dev@db.apache.org> with a subject line containing 
> "CHALLENGE" and the name of the test program, e.g. 
> org.apache.jdo.tck.api.persistencemanager.ThreadSafe.java; and the 
> body of the email containing the details of the challenge.
> The Maintenance Lead will respond within 15 working days with a 
> decision on whether there is an error in the test case. If the issue 
> is found by the Maintenance Lead to be due to an error in the test 
> case, the Maintenance Lead might provide a patch that will be included 
> in the next maintenance revision. If the patch is not provided within 
> 15 working days of the receipt of the challenge, then the test may be 
> put into the TCK directory src/conf/exclude.list and it will not be 
> run as part of the TCK.
> Decisions of the Maintenance Lead may be appealed to the full expert 
> group. A vote of the full expert group will be conducted by the 
> Maintenance Lead, and a majority of votes cast will decide the issue. 
> The Maintenance Lead has one vote, as does each member of the expert 
> group at the time of the vote.
> </spec>
> I'd like to propose a process for handling the test case 
> challenges. I've created a branch 
> https://svn.apache.org/repos/asf/db/jdo/branches/2.0.1 into which we 
> can put the patches referenced by the process. This allows us to 
> manage patches that might differ from the trunk. This is necessary in 
> case we want to modify a test case because the specification is 
> unclear, but change the specification instead of changing the test case. 
> A wiki page has been created to track the TCK 
> challenges http://wiki.apache.org/jdo/TCKChallenges?action=show which 
> can be updated by anyone. The JIRA that tracks each challenge is 
> identified here. Fixes that have already been committed to the trunk 
> will be merged into the 2.0.1 branch.
> The challenger should check out the 2.0.1 branch and verify that the 
> fix as identified in the JIRA is ok. If there is an issue with the 
> fix, the JIRA should be updated with comments. If a resolution is not 
> acceptable by the challenger, then an appeal to the entire expert 
> group should be filed.
> Comments?
> Craig Russell
> clr@apache.org http://db.apache.org/jdo

Michael Bouschen		Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de	http://www.tech.spree.de/
Tel.:++49/30/235 520-33		Buelowstr. 66			
Fax.:++49/30/2175 2012		D-10783 Berlin			

View raw message