Return-Path: Delivered-To: apmail-db-jdo-dev-archive@www.apache.org Received: (qmail 91185 invoked from network); 3 Oct 2006 18:10:51 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 3 Oct 2006 18:10:51 -0000 Received: (qmail 30222 invoked by uid 500); 3 Oct 2006 18:10:50 -0000 Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jdo-dev@db.apache.org Delivered-To: mailing list jdo-dev@db.apache.org Received: (qmail 30198 invoked by uid 99); 3 Oct 2006 18:10:48 -0000 Received: from idunn.apache.osuosl.org (HELO idunn.apache.osuosl.org) (140.211.166.84) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Oct 2006 11:10:48 -0700 X-ASF-Spam-Status: No, hits=0.0 required=5.0 tests= Received: from [212.224.30.66] ([212.224.30.66:49707] helo=service-01.spree.de) by idunn.apache.osuosl.org (ecelerity 2.1.1.8 r(12930)) with ESMTP id F6/77-08153-3A7A2254 for ; Tue, 03 Oct 2006 11:10:45 -0700 Received: from [172.16.2.80] (vpn-server [192.168.16.104]) (authenticated bits=0) by service-01.spree.de (8.13.4/8.13.4/Debian-3) with ESMTP id k93IAZjt022436; Tue, 3 Oct 2006 20:10:39 +0200 Message-ID: <4522A79A.2010103@spree.de> Date: Tue, 03 Oct 2006 20:10:34 +0200 From: Michael Bouschen Organization: Tech@Spree Engineering User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: jdo-dev@db.apache.org CC: JDO Expert Group Subject: Re: Test Case Challenge Process References: <45225C09.2040100@spree.de> <2A55579B-52AF-4D7C-8BE7-19E486C87E68@SUN.com> In-Reply-To: <2A55579B-52AF-4D7C-8BE7-19E486C87E68@SUN.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Hi Craig, > Hi Michael, > > On Oct 3, 2006, at 5:48 AM, Michael Bouschen wrote: > >> 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. > > 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. > >> - 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. > > 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 > >> - Update the Derby dependency to 10.1.3.1. I propose to update the >> Derby dependency in the trunk version, too. > > Good. >> >> I attached a patch for review. Please have a look. > > Looks good modulo changes to api20 and JPOX 1.1.2. > > Thanks for the updates. > > Craig > >> >> 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: >>> >>> >>> >>> 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 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. >>> >>> >>> >>> 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 >> >> Index: tck20/project.xml >> =================================================================== >> --- tck20/project.xml (Revision 452257) >> +++ tck20/project.xml (Arbeitskopie) >> @@ -23,7 +23,7 @@ >> JDO2 Technology Compatibility Kit >> org.apache.jdo >> jdo2-tck >> - 2.0 >> + 2.0.1 >> org.apache.jdo.tck >> Java Data Objects 2.0 (JDO) >> TCK >> The Java Data Objects 2.0 (JDO) API is a standard >> interface-based Java model abstraction of persistence, developed as >> Java Specification Request JSR 243 under the auspices of the Java >> Community Process. >> @@ -39,39 +39,39 @@ >> >> javax.jdo >> jdo2-api >> - 2.0 >> + 2.0.1 >> >> >> org.apache.jdo >> jdo2-enhancer >> - 2.0 >> + 2.0.1 >> >> >> org.apache.jdo >> jdo2-core >> - 2.0 >> + 2.0.1 >> >> >> jpox >> jpox >> - 1.1.0 >> + 1.1.1 >> http://www.jpox.org/docs/download.html >> >> >> jpox >> jpox-enhancer >> - 1.1.0 >> + 1.1.1 >> http://www.jpox.org/docs/download.html >> >> >> org.apache.derby >> derby >> - 10.1.1.0 >> + 10.1.3.1 >> >> >> org.apache.derby >> derbytools >> - 10.1.1.0 >> + 10.1.3.1 >> >> >> junit >> @@ -113,13 +113,13 @@ >> >> jpox >> jpox-c3p0 >> - 1.1.0 >> + 1.1.1 >> http://www.jpox.org/docs/download.html >> >> >> jpox >> jpox-dbcp >> - 1.1.0 >> + 1.1.1 >> http://www.jpox.org/docs/download.html >> >> >> Index: enhancer20/project.xml >> =================================================================== >> --- enhancer20/project.xml (Revision 452257) >> +++ enhancer20/project.xml (Arbeitskopie) >> @@ -25,7 +25,7 @@ >> JDO2 Implementation (Enhancer) >> org.apache.jdo >> jdo2-enhancer >> - 2.0 >> + 2.0.1 >> org.apache.jdo >> Java Data Objects 2.0 (JDO) >> Enhancer >> The Java Data Objects 2.0 (JDO) API is a standard >> interface-based >> @@ -39,12 +39,12 @@ >> >> javax.jdo >> jdo2-api >> - 2.0 >> + 2.0.1 >> >> >> org.apache.jdo >> jdo2-core >> - 2.0 >> + 2.0.1 >> >> >> commons-logging >> Index: project.xml >> =================================================================== >> --- project.xml (Revision 452257) >> +++ project.xml (Arbeitskopie) >> @@ -112,7 +112,7 @@ >> ebengtson >> erik@jpox.org >> 1 >> - Sun Micrsystems >> + JPOX >> >> >> Geir Magnusson, Jr. >> Index: core20/project.xml >> =================================================================== >> --- core20/project.xml (Revision 452257) >> +++ core20/project.xml (Arbeitskopie) >> @@ -25,7 +25,7 @@ >> JDO2 Implementation (Core) >> org.apache.jdo >> jdo2-core >> - 2.0 >> + 2.0.1 >> org.apache.jdo >> Java Data Objects 2.0 (JDO) >> Core >> The Java Data Objects 2.0 (JDO) API is a standard >> interface-based >> Index: api20/project.xml >> =================================================================== >> --- api20/project.xml (Revision 452257) >> +++ api20/project.xml (Arbeitskopie) >> @@ -24,7 +24,7 @@ >> JDO2 API >> javax.jdo >> jdo2-api >> - 2.0 >> + 2.0.1 >> javax.jdo >> Java Data Objects 2.0 (JDO) >> API >> The Java Data Objects 2.0 (JDO) API is a standard >> interface-based > > 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