RFC: Change rules for adding/changing test cases

[Richard Earnshaw]

> 
> 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.