|
Home > Archive > Apache JDO Project > October 2006 > Test Case Challenge Process
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Test Case Challenge Process
|
|
| Craig L Russell 2006-10-02, 7:12 pm |
| | |
| Michael Bouschen 2006-10-03, 1:11 pm |
| 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 10.1.3.1. 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
| |
| Craig L Russell 2006-10-03, 1:11 pm |
| | |
| Michael Bouschen 2006-10-03, 7:11 pm |
| Hi Craig,
> Hi Michael,
>
> On Oct 3, 2006, at 5:48 AM, Michael Bouschen wrote:
>
>
> Changing the API is not possible for test case challenges; we can
> change when we release 2.1. So, I think we need to remove the api20
> project from the branch and should continue to depend on api20 2.0.
OK, I will svn remove api20 from the 2.0.1 branch and change the api20
dependency to 2.0.
>
> I agree we should update the core20, enhancer20, and tck20 to version
> 2.0.1.
>
>
> I don't quite understand. Why not merge the trunk version of
> FetchPlanInterface to 2.0.1 and use JPOX 1.1.2? I'm sure Ilan will be
> happy to file a CHALLENGE if we think it's necessary...
I think as long as the trunk version of FetchPlanInterface is not merged
to the 2.0.1 branch we should go with JPOX 1.1.1. So I propose to use
1.1.1 today and upgrade to 1.1.2 as soon as there is a CHALLENGE for the
FetchPlanInterface test case.
Regards Michael
>
>
> Good.
>
> Looks good modulo changes to api20 and JPOX 1.1.2.
>
> Thanks for the updates.
>
> Craig
>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
--
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
| |
| Craig L Russell 2006-10-03, 7:11 pm |
| |
|
|
|
|