Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Michael Elizabeth Chastain <mec@shout.net>
To: carlton@kealia.com, gdb-patches@sources.redhat.com
Subject: Re: [testsuite] add gdb.cp/gdb1355.exp
Date: Thu, 18 Sep 2003 02:01:00 -0000	[thread overview]
Message-ID: <200309180201.h8I21hCr013787@duracef.shout.net> (raw)

Okay, I'm willing to make it an XFAIL rather than a KFAIL.
I remember those threads.  The XFAIL feels odd but it does stand
for "external" and this bug is indeed a textbook external bug.

As far as making it a FAIL goes, I think David's argument comes down to:
people pay attention to FAIL, but not to XFAIL or KFAIL.  I really don't
like that situation.  I see the question as: whether to fight the
situation and use more accurate XFAIL/KFAIL rather than generic FAIL, or
to acquiesce to situation and give people what they expect to see.
I favor the former.

> Scenario 1: The bug is fixed.  A year later, the bug in question
> regresses.  But, if you just run 'make check', this isn't so obvious:
> no message gets printed in the output, and while the numbers at the
> end of the output will change, those numbers fluctuate for lots of
> reasons.  So it will only be noticed by somebody who actually looks at
> gdb.sum (or does the moral equivalent); ideally that will happen, but
> I'd rather not count on it (especially if the bug is on an obscure
> platform).

I'm willing to count on it.  Because if they just grep for '^FAIL'
then they will miss any tests that barf out completely with an
ERROR at the beginning and abort.  I have little sympathy for
people who analyze gdb.sum that way.

dc> Scenario 2: The fix works on platform A, but not on platform B.  And
dc> nobody using platform B has been paying close enough attention to the
dc> discussion of the bug to realize that the test is supposed to start
dc> passing.  Then, nobody might ever realize that something's wrong:
dc> platform A users think that everything is fine (which is the case for
dc> them), and platform B have no indication from the testsuite that
dc> something is wrong and that the patch didn't work as indicated.

Ah, this is the old scenario "change the KFAIL/XFAIL to a FAIL"
makes people on platform B aware that something has regressed
(I always investigate transitions from KFAIL -> FAIL).
I have some sympathy for this.

dc> Which is why, in the situation at question, I like it that you have the
dc> explicit failure branches, containing an informative comment as to when
dc> the bug occurred - I just want the letter 'k' removed in a few places.
dc> :-)

So we have two proposals here: I'd like to make this an XFAIL,
and David would like to make it a FAIL.

Daniel, or anyone else, do you have a preference?

Michael C


             reply	other threads:[~2003-09-18  2:01 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-18  2:01 Michael Elizabeth Chastain [this message]
2003-09-18 14:27 ` Andrew Cagney
2003-09-18 16:05   ` David Carlton
2003-09-18 15:38 ` David Carlton
  -- strict thread matches above, loose matches on Subject: below --
2003-09-20 22:03 Michael Elizabeth Chastain
2003-09-20 21:59 Michael Elizabeth Chastain
2003-09-18 21:27 Michael Elizabeth Chastain
2003-09-20 21:46 ` Andrew Cagney
2003-09-20 22:31   ` Daniel Jacobowitz
2003-09-21  0:51     ` Andrew Cagney
2003-09-18 21:22 Michael Elizabeth Chastain
2003-09-18 15:33 Michael Elizabeth Chastain
2003-09-20 21:40 ` Andrew Cagney
2003-09-18  0:54 Michael Elizabeth Chastain
2003-09-18  0:56 ` Daniel Jacobowitz
2003-09-18  1:20   ` David Carlton
2003-09-18  1:27     ` David Carlton
2003-09-18  0:00 Michael Elizabeth Chastain
2003-09-18  0:48 ` 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=200309180201.h8I21hCr013787@duracef.shout.net \
    --to=mec@shout.net \
    --cc=carlton@kealia.com \
    --cc=gdb-patches@sources.redhat.com \
    /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