From derby-dev-return-18135-apmail-db-derby-dev-archive=db.apache.org@db.apache.org Mon Apr 03 23:14:39 2006 Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 12045 invoked from network); 3 Apr 2006 23:14:38 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 3 Apr 2006 23:14:38 -0000 Received: (qmail 93650 invoked by uid 500); 3 Apr 2006 23:14:37 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 93624 invoked by uid 500); 3 Apr 2006 23:14:37 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 93615 invoked by uid 99); 3 Apr 2006 23:14:37 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Apr 2006 16:14:37 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [32.97.110.150] (HELO e32.co.us.ibm.com) (32.97.110.150) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Apr 2006 16:14:36 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k33NEDdl018454 for ; Mon, 3 Apr 2006 19:14:13 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k33NAtvm225226 for ; Mon, 3 Apr 2006 17:10:55 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id k33NEDF4020506 for ; Mon, 3 Apr 2006 17:14:13 -0600 Received: from [127.0.0.1] (sig-9-48-123-223.mts.ibm.com [9.48.123.223]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k33NEBGT020462 for ; Mon, 3 Apr 2006 17:14:12 -0600 Message-ID: <4431AC06.7030500@apache.org> Date: Mon, 03 Apr 2006 16:13:10 -0700 From: Daniel John Debrunner User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: derby-dev@db.apache.org Subject: Re: Monitoring/improving code coverage (was Re: code coverage results for trunk - svn revision no 390306) References: <836ae9af0603311535x7864b7dct5913e4a7f8ed239d@mail.gmail.com> <442DC13A.2050205@sun.com> <443190B4.2000001@sbcglobal.net> <44319606.20904@sun.com> <4431A283.8010104@sbcglobal.net> <4431A3FB.3090708@sun.com> In-Reply-To: <4431A3FB.3090708@sun.com> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N David W. Van Couvering wrote: > I think the same could be done for code coverage regressions. If a new > chunk of code is checked in and the numbers drop way way down for a > given module, I think that is cause for concern and a committer could > reasonably insist that the feature is not sufficiently tested and back > out the change, or at least block any future checkins in that area until > enough tests are provided. So we could have applied this rule to JDBC 4.0 checkins. JDBC 4.0 code was checked in, the code coverage numbers decreased and could not increase until the tests could run under JDBC 4.0. In this case requiring the JDBC 4.0 changes be backed out until all the tests ran under JBDC 4.0 seems too drastic. Goes against the model of incremental development. Dan.