The Handling of Software Bugs for the GBT

Mark H. Clark
May 2, 2001
DRAFT

This memorandum describes the reporting, tracking, resolution, and setting of priorities for GBT software defects. Key players are:

user representative: Person who tracks and reviews bugs in regard to their impact on observers and operators, provides a single point of access for software developers and maintainers as well as for the user community. Currently this person is Ron Maddalena.
administrator: Person who tracks bugs through the system as well as oversees the general use of Bugzilla in regard to the policy describe in this memorandum in an attempt to guarantee consistent handling of defects. This person also gathers and publishes statistics on bug resolution progress. He or she is a gadfly to the assignees. Currently this person is Mark Clark.
assignee: Person responsible for resolving a specific bug.
reporter: Person who entered the bug in Bugzilla and is represented in Bugzilla by an email address.
originator: Person who initially discovered the bug and reported it.

Bugzilla

The central tool for handling GBT bugs is the open-source bug database Bugzilla. Besides the GBT's local web site for accessing the database itself, other pages of interest are sites for describing a bug's life cycle under Bugzilla and for bug writing guidelines. I shall adopt Bugzilla's terms in this memorandum, e.g., I will use Bugzilla's term component instead of Ygor's device.

Entering a Bug

Bugs may be entered directly by originators at the GBT's bug entry page or by sending mail to gbtbugs@nrao.edu where the administrator will then enter the bug(s).

The advantage (or disadvantage!) of an originator entering a bug directly on the GBT bug entry page is that he or she becomes the reporter who automatically receives all correspondence and actions taken on the bug. If the administrator receives a mail message and it indicates who the originator is, then that person's email address will be added to the CC list for that bug unless otherwise requested. In the case where the originator is a visiting observer the email is not added to the CC list, however, anyone at anytime may be added to or deleted by request from the CC list for a bug.

The bug entry page has eleven entry fields of which only two must be filled. They are Summary and Component. Of course, as described in the bug writing guidelines, the more information provided to the assignee, the more likely is resolution of the bug.

To enter a bug or be included on the CC list, one must have a Bugzilla login. These will be added as needed

All bugs need to be entered into the database. When a developer (potential assignee) discovers a bug, it should be entered unless the bug will be fixed as part of ongoing work on that component -- either new development or maintenance.

GBT Use of Bugzilla's Bug Life Cycle

The above diagram is a rough summary of the bug's life cycle as provided by Bugzilla. For the GBT this system has been modified somewhat. When a bug is initially entered for the GBT, it defaults to the NEW state rather than the UNCONFIRMED state, partly because it is the responsibility of the assignee to confirm the bug exists as part of the initial analysis, but primarily because we trust our users' word that they have found a problem. If the assignee judges that it is a bona fide defect and has been correctly assigned, he or she accepts the bug by changing the state to ASSIGNED.

When the assignee is convinced that he or she has fixed the defect, it is RESOLVED by setting the resolution to FIXED. For the first month after a bug is RESOLVED it may be VERIFIED only by the originator, after that time the assignee may go ahead and verify it in order to get it off of his or her "to do" list.

A bug may only be closed by the administrator to allow an opportunity for statistics to be gathered to mark progress.

Often a change to a piece a software will create a need for further changes, e.g., a change in a Parameter in a Manager will require a associated change in the user-interface programs. When the secondary change is best done by a different programmer, then the first programmer should not resolve the bug, but rather reassign it to the second programmer.

Classification

A bug's severity level pertains to a specific component, i.e., a bug classified as a blocker indicates that the component is unusable, whereas critical denotes the component is usable for specific modes or short periods of time. The originator may assign a level, but this may be modified by the user representative.

Bugs classified as enhancements may be gathered together as part of a scheduled task for ongoing development. In such cases, the bugs will be closed and the resolution set to later. This process may be initiated by the assignee by pointing out the need for a new target in his or her weekly report.

The user representative sets bugs' priorities. Only levels P1 through P3 will be used.