RFC: Change rules for adding/changing test cases

[Jeff Knaggs]

> > > I definitely agree with the last point. What we do in the GNAT project is
> > > to assign a tracking number to every problem report. The test case is filed
> > > under this tracking number, and all revision history entries (which are 
> > > always detailed, and include how and why the problem was fixed) also include
> > > this same tracking number.
> > 
> > As I mentioned in another mail, not all gcc testcases have
> > corresponding bug reports to refer to, and it's not always efficient
> > to rely on a database halfway across the Internet to give you clues
> > about how to fix bugs a testcase catches.
> 
> But equally, the reason why a test fails on one target may be completely 
> different from the reason why it fails on another; so I see minimal uses 
> for such comments.  In the end, the only real way to debug a problem is to 
> run the compiler under a debugger and look at what is really going wrong.

That's right, "in the end," one resorts to a debugger. However, _in the begining_
one takes a quick look for clues. Any tools that can be brought to the table
during triage are useful; yes, it might be a dead-end; but that, in and of itself,
is useful information -- knowing what a bug _is not_ is often half the battle
of discovering what _it is_. I'm confident that truly mis-leading or useless
commentary would be rejected/modified as part of the normal patch submission
process. 


Jeff Knaggs

PS I don't intend to turn this thread into a discussion on 
debugging techniques. I won't be responding to further arguments
along this line.