On Sun, Jun 10, 2007 at 00:35:33 -0700, Junio C Hamano wrote: > "Martin Langhoff" <martin.langhoff@xxxxxxxxx> writes: > > So you can tell your bugtracker > > - which commit fixed it -- usually auto-linked if you include the > > bugnumber in the commit message > > - which commit added the test -- auto linked as above > > - which commit introduced the bug -- if such thing exists and someone > > digs it up > > All of your examples are going from a single bug to commits, but > from a release person's point of view, you are never interested > in a single bug, just like a top-level maintainer is never > interested in a single file. A release person would want to go > in the reverse direction: from a commit range to a set of bugs. > What bugs were fixed and what regressions were introduced during > this release cycle. While embedded ticket numbers in commit log > messages would certainly help, a change made to fix a particular > bug may fix another as its side effect, and the develeoper who > did the change may not know about the latter when the commit log > message is written. It would be really useful to have a tool, that could link a bug report to a test case demonstrating it and reporting whenever output of that test case changes. This would make it much easier for developer to see which bugs he might have fixed when doing a refactoring. It should probably report not just unexpected success, but also change to the error output, because the test case does not have to be 100% correct. That is if you have a test case that prints: testFoobar FAIL "foo" != "Bar" and than starts to say: testFoobar FAIL "foo" != "Foo" the problem is probably fixed, but the test still fails because of minor error in the expected output string. -- Jan 'Bulb' Hudec <bulb@xxxxxx>
Attachment:
signature.asc
Description: Digital signature
