From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2042 invoked by alias); 27 Nov 2003 19:17:59 -0000 Mailing-List: contact mauve-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: mauve-discuss-owner@sources.redhat.com Received: (qmail 2035 invoked from network); 27 Nov 2003 19:17:59 -0000 Received: from unknown (HELO gash2.peakpeak.com) (207.174.178.17) by sources.redhat.com with SMTP; 27 Nov 2003 19:17:59 -0000 Received: from fleche.redhat.com (lt658_076.peakpeak.com [199.165.157.76] (may be forged)) by gash2.peakpeak.com (8.9.3/8.9.3.1) with ESMTP id MAA16743 for ; Thu, 27 Nov 2003 12:17:58 -0700 Received: by fleche.redhat.com (Postfix, from userid 1000) id 963164F8286; Thu, 27 Nov 2003 12:08:05 -0700 (MST) To: graydon hoare Cc: mauve-discuss@sources.redhat.com Subject: Re: JUnit integration References: <874qwqjziy.fsf@dub.venge.net> From: Tom Tromey Reply-To: tromey@redhat.com X-Attribution: Tom X-Zippy: .. Now KEN and BARBIE are PERMANENTLY ADDICTED to MIND-ALTERING DRUGS.. Date: Thu, 27 Nov 2003 19:17:00 -0000 In-Reply-To: <874qwqjziy.fsf@dub.venge.net> Message-ID: <87fzg9r5nu.fsf@fleche.redhat.com> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-q4/txt/msg00008.txt.bz2 >>>>> "graydon" == graydon hoare writes: graydon> these are attached. but the more general question -- the next logical graydon> step in my mind -- is whether to start merging mauve into classpath so graydon> it configures and builds "naturally" as part of the day-to-day graydon> development cycle on classpath (using the classpath build dir, graydon> compiler and VM selection, for example, and running as the nominal graydon> "make check" for classpath). I'm wondering how taboo an idea that is, graydon> whether anyone would mind if I had a go at it. First, different VMs use Classpath differently. So this may matter. Second, traditionally Mauve hasn't required any copyright assignments of any sort. Collecting those now would be hard to impossible (e.g., we got a bunch of tests from HP years back, no clue who to contact about those). So it isn't clear Mauve meets GNU requirements for checkin... Third, it is useful to be able to run Mauve against non-Classpath JVMs, in particular the Sun JVM. This lets us do compatibility testing; in fact an item on my infrastructure to-do list is to run Mauve against the JDK nightly and compare the results, to see if we're getting bad tests. Anyway, those are issues, potential or otherwise. I definitely agree that making it easier to run Mauve against Classpath changes would be helpful. For libgcj we "solved" this problem by having some wrapper code in the test suite. Many libgcj developers probably don't run this regularly though :-(. Tom