From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17636 invoked by alias); 24 Oct 2002 21:58:32 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 17590 invoked from network); 24 Oct 2002 21:58:31 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 24 Oct 2002 21:58:31 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id g9OLb0w10683 for ; Thu, 24 Oct 2002 17:37:01 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g9OLwTl27899; Thu, 24 Oct 2002 17:58:30 -0400 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g9OLwTD26466; Thu, 24 Oct 2002 14:58:29 -0700 Message-ID: <3DB86D05.6261C67@redhat.com> Date: Thu, 24 Oct 2002 14:58:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Andrew Cagney CC: Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: [patch/rfc] Remove all setup_xfail's from testsuite/gdb.mi/ References: <3DB83EC1.6070609@redhat.com> <20021024190956.GA20879@nevyn.them.org> <3DB84A34.6070801@redhat.com> <20021024195912.GA12331@nevyn.them.org> <3DB864A2.6010801@redhat.com> <20021024212629.GA16334@nevyn.them.org> <3DB86B1A.8050003@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-10/txt/msg00524.txt.bz2 Andrew Cagney wrote: > > > On Thu, Oct 24, 2002 at 05:22:42PM -0400, Andrew Cagney wrote: > > > >> I think the patch, regardless of KFAIL, is still technically correct. It > >> fixes a bug: the XFAILs are all wrong so removing them changes the > >> testsuite so that the numbers it reports better reflect reality. It's > >> just unfortunate that part of the reality is a jump in testsuite > >> failures. Remember, the XFAILs were originally added to artifically > >> deflate the test failure rate. > > > > > > As you wish. Michael's already said he just ignores gdb.mi; if it > > picks up this many new failures, probably so will I. > > So ..., what will happen when I submit an equivalent patch for one of > the other directories? > > > I don't agree > > that it's technically correct; the XFAILs were being used for a > > slightly suboptimal meaning since KFAIL wasn't available. They aren't > > real failures no matter which way I look at it. > > The ones I know about were real failures that reflected real bugs. They > were XFAILed to supress a bug that wasn't going to be fixed. Grab an > old GDB and check the comments that go with the a29k XFAILs. That is > very different to XFAILing something because it isn't possible to fix. > > >> > Would it be > >> > hard to file PRs for all the failures you see and mark them KFAIL? > > > >> > >> I think that would be a step backwards as all it would do is fill the > >> bug database with reports like ``test failed''. > > > > > > What do you want in the database then? > > An analysis of the bug. > > >> At least this does move things forward - it puts the tesuite in a state > >> where everyone and everyone can incrementally do the marking. > > > > > > But nobody will... > > In one hit, or here and there? I know I will. I just won't be spending > a solid week reviewing all of them. Well, so far we've got two nays. Why don't Daniel and I shut up, and wait to see if there are any yays?