There are currently 14 challenges filed by BEA that need to be resolved within 15 working days of receipt. <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: [email protected] 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=""> 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? |
smime.p7s
Description: S/MIME cryptographic signature
