Communicating that a bug is fixed
Developers should make every effort to ensure that a fix does not induce side-effects. To that end they should system test their fixes under a number of reasonable/possible usage scenarios.
IMPORTANT: When testing a fix use a clean build produced using the application's main ant build script; this will help avoid situations where an IDE-based build is fortuitously successful due to IDE-specific library configuration settings which are not reflected in the ant script.
After a defect has been fixed, the individual that performed the fix should:
- Check the fix in CVS. For each file involved provide a detailed CVS comments that contains (1) the Mantis defect ID of the bug being fixed, and (2) a description of the change applied to the file. An example of an acceptable CVS entry:
Fix for bug #376, comment #2. Changed the type of threshold static fields from double to float, as precisions issues were resulting in the comparison ((float x) >= (double x)) returning "false".
- Go to Mantis entry for the corresponding bug and:
- Change the bug "Passed Code Review" field.
- Change the bug status to "resolved" and set the resolution attribute to "fixed" (or whichever among the available values properly describes the action taken to resolve the bug).
- Enter a detailed description of the fix along with a list of the files that were modified. See for example the comments in bug #376.
- Change the defect's "Resolution" field to "fixed".
- Change the defect's "Development status" field to "Inactive".
Recording detailed information about the nature of a fix is useful in case that the same bug reappears (and this in not an unusual event): it provides a good point to start for investigating what the source of the problem might be.