Communicating that a bug is fixed

From Informatics

Revision as of 17:21, 20 August 2009 by Floratos (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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.

Personal tools