This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Change rules for adding/changing test cases
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: Richard dot Earnshaw at arm dot com, rth at redhat dot com, dewar at gnat dot com, gcc at gcc dot gnu dot org
- Date: Thu, 21 Mar 2002 15:32:13 +0000
- Subject: Re: RFC: Change rules for adding/changing test cases
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
>
> To me, it looks like this:
>
> Patches, changelogs, and PRs tell you this: That it's broken, how to
> reproduce it, what it looks like when it's broken, and what the patch
> was that fixed it.
>
> The key missing detail is *why* it was broken - the core issue that
> caused the bug, and the reason behind why the fix actually fixes it.
>
> This type of hint to the next developer just doesn't exist in anything
> today, and *that* is what I think should go in the testcase.
> Something like "if this testcase fails, one thing to look at is foo,
> because sometimes bar causes grill."
>
> Just little handy notes to the next bug fixer to try to cut down on
> debug time.
I don't dispute any of that. I just think the testcase isn't necessarily
the right place for it; indeed I think this is exactly the information
that should be added to the PR when it is closed. Far too often a case is
being closed with just:
"Fixed with <changelog entry>"
Or worse:
"fixed on trunk"
R.