From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8593 invoked by alias); 3 Jan 2003 23:19: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 8579 invoked from network); 3 Jan 2003 23:19:17 -0000 Received: from unknown (HELO duracef.shout.net) (204.253.184.12) by 209.249.29.67 with SMTP; 3 Jan 2003 23:19:17 -0000 Received: (from mec@localhost) by duracef.shout.net (8.11.6/8.11.6) id h03NIxn21332; Fri, 3 Jan 2003 17:18:59 -0600 Date: Fri, 03 Jan 2003 23:19:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200301032318.h03NIxn21332@duracef.shout.net> To: carlton@math.stanford.edu, drow@mvista.com Subject: Re: [patch/rfc] KFAIL gdb.c++/annota2.exp watch triggered on a.x Cc: gdb-patches@sources.redhat.com X-SW-Source: 2003-01/txt/msg00117.txt.bz2 Daniel J says: > OK; you're definitely right. How about a compromise: we agree not to > remove kfail patterns in the testsuite, but instead replace them with > specific fail patterns and a commented out reference to the failure. > That makes life much simpler. That sounds good to me. Before the bug fix: -re "known bad pattern" { kfail "gdb/38" "test name" } After the bug fix: -re "known bad pattern" { # this was pr gdb/38 fail "test name" } If somebody leaves a KFAIL pointing to a closed bug, and the KFAIL fires, then eventually somebody will notice that the KFAIL points to a closed bug -- which means that the bug has re-appeared. The bug ID# then provides valuable history. If somebody applies the 'bug fix' too soon, or it doesn't work in all cases, then the person investigating it will see the comment about "gdb 38" in the test script source pretty quickly. Michael C