Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@redhat.com>
To: Andrew Cagney <ac131313@redhat.com>
Cc: dejagnu@gnu.org, gdb@sources.redhat.com,
	Fernando Nasser <fnasser@redhat.com>
Subject: Re: Print KFAIL's in dejagnu summary?
Date: Sat, 27 Sep 2003 10:34:00 -0000	[thread overview]
Message-ID: <vt2llsarh02.fsf@zenia.home> (raw)
In-Reply-To: <3F7361BB.1000706@redhat.com>


Andrew Cagney <ac131313@redhat.com> writes:
> At present KFAILs are supressed from the summary output (the stuff on
> the terminal from "make check").  I'd like to change this so that
> KFAILs, just like FAILs, are included in the summary.  A KFAIL, just
> like a FAIL, indicates a bug in the system under test, and hence
> should be included in the summary.
> 
> Having seen this feature in action for a year now, I think it's
> reasonable to conclude that people are ignoring KFAILed tests just
> like they ignored GDB's bogus XFAIL tests that went before.

I think this might be a good thing.  They certainly are failures.

I'm usually working in one of two modes:

- I'm evaluating a particular change.  Here I do before-and-after
  comparisons of the .sum files, to look for regressions; what appears
  in the summary output makes no difference to me at all, so the
  change you suggest wouldn't affect me.

- I'm stabilizing a target for a release.  Here, every failure is of
  potential interest to me, and KFAILs are no exception.  But I
  usually work from the gdb.sum files in this situation too, so again,
  it doesn't make much difference.

When you say "I think it's reasonable to conclude that people are
ignoring KFAILed tests", I get this image of someone running a 'make
check', being shocked to see a blip in the output there, and getting
hot and bothered about fixing it.  But it's hard for me to imagine
someone actually working in such an impulsive way; bugs take (me) too
long to fix to just dive in when I hadn't planned on it.  I'm always
more directed about what I'm going to work on.  I do other things for
fun.

If other folks are like me, then I don't think the change you suggest
will have much effect on the rate at which bugs are fixed in GDB.
(Not that that was the only point in its favor.)


  parent reply	other threads:[~2003-09-27  4:33 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-25 21:56 Andrew Cagney
2003-09-26  0:03 ` David Carlton
2003-09-27 15:46   ` Andrew Cagney
2003-09-29 19:46     ` David Carlton
2003-09-27 10:34 ` Jim Blandy [this message]
2003-10-03 15:52 ` Rob Savoye
2003-09-25 22:13 Michael Elizabeth Chastain
2003-09-29 20:05 Michael Elizabeth Chastain
2003-10-03 15:57 Michael Elizabeth Chastain
2003-10-03 16:06 ` Rob Savoye
2003-10-03 23:28   ` Ben Elliston

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=vt2llsarh02.fsf@zenia.home \
    --to=jimb@redhat.com \
    --cc=ac131313@redhat.com \
    --cc=dejagnu@gnu.org \
    --cc=fnasser@redhat.com \
    --cc=gdb@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