From: David Carlton <carlton@math.stanford.edu>
To: Michael Elizabeth Chastain <mec@shout.net>
Cc: drow@mvista.com, gdb-patches@sources.redhat.com
Subject: Re: [patch/rfc] KFAIL gdb.c++/annota2.exp watch triggered on a.x
Date: Fri, 03 Jan 2003 22:27:00 -0000 [thread overview]
Message-ID: <ro1d6ndlviu.fsf@jackfruit.Stanford.EDU> (raw)
In-Reply-To: <200301032212.h03MCQa20253@duracef.shout.net>
On Fri, 3 Jan 2003 16:12:26 -0600, Michael Elizabeth Chastain <mec@shout.net> said:
> One advantage of David's code is that when the bug gets fixed,
> people see a more informative message for a while: "KPASS gdb/38"
> rather than "PASS".
Actually, I don't consider that an advantage at all: any KPASS seems
to me to demand an investigation, and should be eradicated. So, when
somebody fixes this bug, I think that somebody should change the
KPASSes to plain old normal PASSes. (As well as remove or comment out
the KFAIL branches, as I said in my response to Daniel that crossed
your e-mail.)
Basically, I see three different priorites of output messages (I'm
ignoring ERROR/UNSUPPORTED/etc. for now):
1) PASS: everything is peachy keen.
2) KFAIL/XFAIL: something doesn't work right, but at least we know
that it doesn't work right.
3) FAIL/KPASS/XPASS: either something doesn't work right that we
weren't aware of, or something does work right when we think it
shouldn't.
And, in the mythical utopia where the GDB testsuite has been carefully
audited to have KFAILs added where appropriate, messages in category 3
are grounds for immediate investigation, whereas messages in
categories 1 and 2 aren't grounds for immediate investigation.
So, when bugs have been fixed, I don't want to see KPASS (because that
gives the misleading impression that we think it hasn't been fixed) or
KFAIL (because that gives the misleading impression that we're aware
that the bug hasn't, in fact, been fixed after all).
David Carlton
carlton@math.stanford.edu
next prev parent reply other threads:[~2003-01-03 22:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-03 22:12 Michael Elizabeth Chastain
2003-01-03 22:27 ` David Carlton [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-01-03 23:19 Michael Elizabeth Chastain
2003-01-03 21:36 David Carlton
2003-01-03 21:39 ` Daniel Jacobowitz
2003-01-03 21:48 ` David Carlton
2003-01-03 21:51 ` Daniel Jacobowitz
2003-01-03 22:14 ` David Carlton
2003-01-03 22:30 ` Daniel Jacobowitz
2003-01-03 22:57 ` David Carlton
2003-01-09 17:10 ` David Carlton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ro1d6ndlviu.fsf@jackfruit.Stanford.EDU \
--to=carlton@math.stanford.edu \
--cc=drow@mvista.com \
--cc=gdb-patches@sources.redhat.com \
--cc=mec@shout.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox