From: Fernando Nasser <fnasser@redhat.com>
To: Andrew Cagney <ac131313@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch/rfc] Remove all setup_xfail's from testsuite/gdb.mi/
Date: Wed, 15 Jan 2003 17:25:00 -0000 [thread overview]
Message-ID: <3E259999.8000503@redhat.com> (raw)
In-Reply-To: <3E25845A.4030405@redhat.com>
Andrew Cagney wrote:
> Fernando,
>
> What is the resolution of this thread?
> http://sources.redhat.com/ml/gdb-patches/2002-10/msg00508.html
> (you'll probably want to read all of it :-)
> (I'm now going back and emptying my mail box :-()
>
> Andrew
>
Hi Andrew,
I am just starting to think about this, so bear with me while I think aloud a
little bit :-) There are lots of good points made on that discussion and I
don't think this is a clear cut yet or no, lets vote, or anything like that. I
am trying to see if I can collect all good suggestions and propose a course of
action.
It seems that a widespread concern is not to through the baby with the water.
On the other hand there is the feeling that we do not act now nothing will ever
happen. And we all agree that many xfails were added incorrectly.
Independently of the "big plan", one thing is clear. If you know that a xfail
is incorrect (I mean, know for good), then it should be ripped off. But read on...
Maybe we may not be in full agreement here, but I think it would be nice to
enter a bug report even if does not include a full analysis -- that should come
eventually. Something like "something is wrong with the '--xxx-yyy' command
output" may eventually cause someone to look into it. And you can make the
xfail a kfail in that case, which is much better. But I know it is much more
work than just removing the xfail and letting the test fail -- you would have to
enter 28 bug reports just for the MI tests. Still sounds like a better approach
to me, but there is no consensus on it.
W.r.t. the non-MI xfails, looking at Michael's reports, more than half of them
seem to be related to stabs problems in different gcc versions. They should be
conditional to stabs and the compiler version and are not, but otherwise they
are valid xfails (by definition). There are a couple of XPASSes that are always
there, so we have at least two obsolete XFAILs that we can get rid off (just
look at a dwarf-2 test result -- those 2).
The remaining ones are 71 (take or add one or two). We can use the gcc 3.2.1
results on RHL 8.0 to determine which ones they are. If seven of us (the
magnificent seven? :-) agree to look into 10 of those each and enter even a
basic bug report we can kfail them all and use the bug database to track the
resolution.
As I said, this is just a brainstorm. Please comment.
Regards to all,
Fernando
P.S.: Michael's table is very revealing. See, for instance,
http://www.shout.net/~mec/sunday/2003-01-09/Counts.html
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
next prev parent reply other threads:[~2003-01-15 17:25 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-24 11:41 Andrew Cagney
2002-10-24 12:09 ` Daniel Jacobowitz
2002-10-24 12:29 ` Andrew Cagney
2002-10-24 12:58 ` Daniel Jacobowitz
2002-10-24 14:22 ` Andrew Cagney
2002-10-24 14:26 ` Daniel Jacobowitz
2002-10-24 14:39 ` Michael Snyder
2002-10-24 16:31 ` Andrew Cagney
2002-10-24 16:36 ` Michael Snyder
2002-10-24 14:50 ` Andrew Cagney
2002-10-24 14:58 ` Michael Snyder
2002-10-24 15:31 ` Ben Elliston
2002-10-24 16:44 ` Andrew Cagney
2002-10-24 17:35 ` Michael Snyder
2002-10-24 18:25 ` Andrew Cagney
2002-10-24 14:18 ` Michael Snyder
2002-10-24 14:32 ` Andrew Cagney
2002-10-24 14:39 ` David Carlton
2002-10-24 14:57 ` Andrew Cagney
2002-10-24 15:00 ` Michael Snyder
2002-10-24 15:26 ` David Carlton
2002-10-24 15:36 ` Andrew Cagney
2003-01-15 15:55 ` Andrew Cagney
2003-01-15 17:25 ` Fernando Nasser [this message]
2003-01-16 16:53 ` Andrew Cagney
2003-01-16 17:05 ` Daniel Jacobowitz
2003-01-16 19:03 ` Andrew Cagney
2003-01-16 19:55 ` Daniel Jacobowitz
2003-01-15 17:44 Michael Elizabeth Chastain
2003-01-15 17:51 ` Daniel Jacobowitz
2003-01-16 14:27 ` Fernando Nasser
2003-01-16 14:30 ` Daniel Jacobowitz
2003-01-16 14:46 ` Fernando Nasser
2003-01-16 14:52 ` Daniel Jacobowitz
2003-01-16 15:46 ` Andrew Cagney
2003-01-16 14:20 ` Fernando Nasser
2003-01-16 17:07 Michael Elizabeth Chastain
2003-01-16 17:12 Michael Elizabeth Chastain
2003-01-16 20:06 Michael Elizabeth Chastain
2003-01-16 20:12 ` Daniel Jacobowitz
2003-01-17 14:12 ` Fernando Nasser
2003-01-17 16:05 ` Andrew Cagney
2003-01-17 14:26 ` Fernando Nasser
2003-01-17 19:00 Michael Elizabeth Chastain
2003-01-17 19:16 ` David Carlton
2003-01-17 19:20 ` David Carlton
2003-01-17 19:30 ` Daniel Jacobowitz
2003-01-17 19:28 ` Andrew Cagney
2003-01-17 19:28 Michael Elizabeth Chastain
2003-01-17 19:34 ` Daniel Jacobowitz
2003-01-17 19:32 Michael Elizabeth Chastain
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=3E259999.8000503@redhat.com \
--to=fnasser@redhat.com \
--cc=ac131313@redhat.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