public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Guenther <richard.guenther@gmail.com>
To: Mike Stump <mikestump@comcast.net>
Cc: Rainer Orth <ro@cebitec.uni-bielefeld.de>,
	Janis Johnson <janisjo@codesourcery.com>,
		gcc-patches@gcc.gnu.org, Jan Hubicka <jh@suse.cz>
Subject: Re: [testsuite] remove XFAIL for all but ia64 for g++.dg/tree-ssa/pr43411.C
Date: Thu, 26 May 2011 17:25:00 -0000	[thread overview]
Message-ID: <BANLkTinqZK=_QbcxZadXq_VBOT7CWKQD6Q@mail.gmail.com> (raw)
In-Reply-To: <6C35D651-A8CC-4B94-B673-FDE0FD69B71E@comcast.net>

On Thu, May 26, 2011 at 5:16 PM, Mike Stump <mikestump@comcast.net> wrote:
> On May 26, 2011, at 2:25 AM, Richard Guenther wrote:
>> The XPASS is suprious - that's the whole point of XPASSes.  It should
>> FAIL (well, XFAIL).  A patch making it PASS is bogus.
>
> There are deeper reasons for my position.  Take a look at:
>
>  http://google1.osuosl.org:8011/waterfall
>
> the idea is to use the expected state of the testcases to determine if the color should be green or not.  The best use of a system like this is when the usual state is green, and any time a red appears, it is turned back to green, in time measures in minutes or hours, not days or years.  Now, do you think there is any value add to having a testing system that displays testing results across many platforms on a regular basis like this?  If so, how do you propose to decide on wether the color should be green or red?

It's always red on a transition.  Whether an XPASS or XFAIL is red on
its own needs human interaction (understanding of the testcase and
why it now XPASSes or XFAILs).  The red on the transition should
cause the human that did that transition to do that inspection.

Richard.

  reply	other threads:[~2011-05-26 15:59 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-24 20:40 Janis Johnson
2011-05-25  6:20 ` Mike Stump
2011-05-25  9:58 ` Rainer Orth
2011-05-25 10:29   ` Richard Guenther
2011-05-25 13:38     ` Jan Hubicka
2011-05-27  3:57       ` Janis Johnson
2011-05-27  9:54         ` Richard Guenther
2011-05-25 19:24   ` Mike Stump
2011-05-26 10:43     ` Richard Guenther
2011-05-26 16:13       ` Mike Stump
2011-05-26 17:25         ` Richard Guenther [this message]
2011-05-27  3:55           ` Mike Stump

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='BANLkTinqZK=_QbcxZadXq_VBOT7CWKQD6Q@mail.gmail.com' \
    --to=richard.guenther@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=janisjo@codesourcery.com \
    --cc=jh@suse.cz \
    --cc=mikestump@comcast.net \
    --cc=ro@cebitec.uni-bielefeld.de \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).