This is the mail archive of the
mailing list for the GCC project.
Re: RFC: Change rules for adding/changing test cases
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: Richard dot Earnshaw at arm dot com, DJ Delorie <dj at redhat dot com>, dewar at gnat dot com, gcc at gcc dot gnu dot org
- Date: Thu, 21 Mar 2002 11:21:00 +0000
- Subject: Re: RFC: Change rules for adding/changing test cases
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw 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
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.