This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]