From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9425 invoked by alias); 18 Sep 2003 21:22:17 -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 9404 invoked from network); 18 Sep 2003 21:22:16 -0000 Received: from unknown (HELO concert.shout.net) (204.253.184.25) by sources.redhat.com with SMTP; 18 Sep 2003 21:22:16 -0000 Received: from duracef.shout.net (duracef.shout.net [204.253.184.12]) by concert.shout.net (8.12.10/8.12.10) with ESMTP id h8ILMDHt010068; Thu, 18 Sep 2003 16:22:13 -0500 Received: from duracef.shout.net (localhost [127.0.0.1]) by duracef.shout.net (8.12.10/8.12.9) with ESMTP id h8ILMDVd000428; Thu, 18 Sep 2003 16:22:13 -0500 Received: (from mec@localhost) by duracef.shout.net (8.12.10/8.12.9/Submit) id h8ILMDTq000427; Thu, 18 Sep 2003 17:22:13 -0400 Date: Thu, 18 Sep 2003 21:22:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200309182122.h8ILMDTq000427@duracef.shout.net> To: carlton@kealia.com Subject: Re: [testsuite] add gdb.cp/gdb1355.exp Cc: gdb-patches@sources.redhat.com X-SW-Source: 2003-09/txt/msg00405.txt.bz2 David C writes: 1) The bug is completely undiagnosed. 2) The bug is diagnosed but known not to be fixed. 3) The bug was diagnosed, thought to be fixed, but not actually fixed. We have three states here, and only two bug labels. I agree with this state list. The problem is that the difference between the states exists only in our minds. (gdb) print 2+2 5 dc> That's the static way of looking at the situation; another is a dc> dynamic way, namely how will the output of the tests change between dc> runs. In both of our proposals, if a regression pops up, we'll see a dc> state transition: either PASS=>FAIL or PASS=>KFAIL. I agree. To me, that's the important part. People should be looking for transitions (comparing two gdb.sum's) rather than looking at levels (looking at a single gdb.sum ... and then they ignore the ERROR, WARNING, KFAIL, XFAIL, UNRESOLVED, UNTESTED, UNSUPPORTED results too!) dc> But my proposal also guarantees that there will always be a state dc> transition after a bug is (thought to be) fixed: either KFAIL=>PASS or dc> KFAIL=>FAIL. In your proposal, the latter scenario won't lead to a dc> state transition: it will remain KFAIL. Ah, I'm really starting to see where you're coming from, with the idea that someone should change the test script after someone fixes the bug. I guess it's not so bad. I'm starting to come around. Michael C