From general-return-719-apmail-logging-general-archive=logging.apache.org@logging.apache.org Mon Feb 06 17:00:14 2006 Return-Path: Delivered-To: apmail-logging-general-archive@www.apache.org Received: (qmail 99124 invoked from network); 6 Feb 2006 17:00:12 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 6 Feb 2006 17:00:12 -0000 Received: (qmail 51917 invoked by uid 500); 6 Feb 2006 16:59:56 -0000 Delivered-To: apmail-logging-general-archive@logging.apache.org Received: (qmail 51772 invoked by uid 500); 6 Feb 2006 16:59:55 -0000 Mailing-List: contact general-help@logging.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: "Logging General" List-Id: Delivered-To: mailing list general@logging.apache.org Received: (qmail 51761 invoked by uid 99); 6 Feb 2006 16:59:55 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Feb 2006 08:59:55 -0800 X-ASF-Spam-Status: No, hits=-3.8 required=10.0 tests=DNS_FROM_RFC_ABUSE,RCVD_IN_BSP_TRUSTED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of mwomack@google.com designates 216.239.45.12 as permitted sender) Received: from [216.239.45.12] (HELO smtp-out.google.com) (216.239.45.12) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Feb 2006 08:59:54 -0800 Received: from nappa.corp.google.com (nappa.corp.google.com [172.24.0.4]) by smtp-out.google.com with ESMTP id k16GxXbR002090 for ; Mon, 6 Feb 2006 08:59:33 -0800 Received: from smtp-out2.google.com (fpe11.prod.google.com [10.253.5.11]) by nappa.corp.google.com with ESMTP id k16GxLi3008204 for ; Mon, 6 Feb 2006 08:59:29 -0800 Received: by smtp-out2.google.com with SMTP id 11so110950fpe for ; Mon, 06 Feb 2006 08:59:29 -0800 (PST) Received: by 10.253.3.20 with SMTP id 20mr36927fpc; Mon, 06 Feb 2006 08:59:29 -0800 (PST) Received: by 10.253.5.6 with HTTP; Mon, 6 Feb 2006 08:59:29 -0800 (PST) Message-ID: <284ea76b0602060859g627f182cm6f4d2840c9d15dee@mail.google.com> Date: Mon, 6 Feb 2006 08:59:29 -0800 From: Mark Womack Sender: mwomack@google.com To: Logging General Subject: Re: [VOTE] Release log4j-1.3a8 official In-Reply-To: <60DBEF4D-04B0-4C46-826B-607F464EA5AC@apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <284ea76b0602011144r5ea3548bt6ff2d386204afc33@mail.google.com> <60DBEF4D-04B0-4C46-826B-607F464EA5AC@apache.org> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On Saturday, I instrumented the TimedLocationWatchdog code to see if I could get a snapshot of what was going wrong, but of course after doing that, the test never failed, after repeated tries. It occured to me last night that it could be related to a difference in JDK 1.3 vs JDK 1.4 (I was doing everything in 1.3). So, I will be at it again this evening. However, I don't think we should stop the alpha8 release for this. I will create a bug to track the issue (if there isn't already an apporpriate one). But previously the test was just left out of the main test suite. At least now there is a test that can fail (intermittently). It is a new feature, not on a critical path for most users, and all the other parts of the alpha8 release need to get into the user community in general for review. If this was beta or rc, I'd have a much different opinion. -Mark On 2/1/06, Curt Arnold wrote: > > On Feb 1, 2006, at 1:44 PM, Mark Womack wrote: > > > Well, it is a good nit. This particular test doesn't always fail > > though. Locally on my machine it failed once, and after looking at > > the code, I ran it again and it worked. My guess is that it has > > something to do with the copying of the config file not changing the > > date so that the watchdog triggers or conceiveably a bug in the > > FileWatchdog code someplace. > > > > There is something similar that I have mentioned related to the > > TimeBasedRolling scheme as well, though it does not seem to show up in > > the Gump radar. I get it fairly often locally. > > > > -Mark > > Gump is not consistently failing, but it isn't a desirable practice > to be issuing releases while Gump is failing or immediately after > Gump starts passing. The test was recently added at which time they > would pass on Windows but fail on most Unix platforms. I modified > them to get them to pass consistently on my boxes and apparently pass > inconsistently on Gump. I do not think it reflects a regression in > the code base, but either the fragility of the test or a bug that has > been latent in the code for some time. > > Omitting the test would not change the distribution since the unit > tests are not included. It would only silence Gump from reminding us > that we have either a fragile test or a latent bug. I think > releasing an alpha under these conditions, while undesirable, is > acceptable. >