Re: RFC: Change rules for adding/changing test cases

[Richard Earnshaw <rearnsha at arm dot com>]

> The biggest use I see for such comments is for when you find
> that some test case fails on some new target due to the 
> non-portability of the test case itself.  If you have docs
> for what it supposed to be tested, one can determine if it
> makes sense to modify the test case or disable it for the new
> target.

I've no objection to the PR number being added to a test case: from that 
you can get to the entire history of the bug.

But I see little point in cluttering up the tests with information that 
substantially is a duplicate of what we already have in gnats/bugzilla etc.

Cross-referencing good.  Duplication not so good.

This of course leaves open the question of what should happen when a bug 
is reported into, for the sake of example, the redhat/gnupro bug data base 
and for obvious reasons has to be kept confidential.

There is a model of development/configuration management that says that 
every change to a product should be matched to a change request/defect 
report/enhancement specification etc, etc.  I'm not suggesting that we 
should go down that route with gcc, it's probably overkill for this sort 
of community development, but it does have the advantage that the 
discussions/patches in the mailing lists would be more closely linked with 
the eventual changes made to the compiler.  At present there is no easy 
way to get from a patch back to the reasons for the change.

R.