This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [testsuite] add gdb.cp/gdb1355.exp
- From: Michael Elizabeth Chastain <mec at shout dot net>
- To: carlton at kealia dot com
- Cc: gdb-patches at sources dot redhat dot com
- Date: Thu, 18 Sep 2003 17:22:13 -0400
- Subject: Re: [testsuite] add gdb.cp/gdb1355.exp
David C writes:
1) The bug is completely undiagnosed.
2) The bug is diagnosed but known not to be fixed.
3) The bug was diagnosed, thought to be fixed, but not actually fixed.
We have three states here, and only two bug labels.
I agree with this state list. The problem is that the difference
between the states exists only in our minds.
(gdb) print 2+2
5
dc> That's the static way of looking at the situation; another is a
dc> dynamic way, namely how will the output of the tests change between
dc> runs. In both of our proposals, if a regression pops up, we'll see a
dc> state transition: either PASS=>FAIL or PASS=>KFAIL.
I agree. To me, that's the important part. People should be looking
for transitions (comparing two gdb.sum's) rather than looking at
levels (looking at a single gdb.sum ... and then they ignore the
ERROR, WARNING, KFAIL, XFAIL, UNRESOLVED, UNTESTED, UNSUPPORTED
results too!)
dc> But my proposal also guarantees that there will always be a state
dc> transition after a bug is (thought to be) fixed: either KFAIL=>PASS or
dc> KFAIL=>FAIL. In your proposal, the latter scenario won't lead to a
dc> state transition: it will remain KFAIL.
Ah, I'm really starting to see where you're coming from, with the
idea that someone should change the test script after someone
fixes the bug.
I guess it's not so bad. I'm starting to come around.
Michael C