CASEVision/Tracker: SGI's Bug Tracking Application

The CASEVision/Tracker application is used to track problem reports (bugs), system enhancement requests, engineering changes, documentation updates, and similar requests. It is also a highly flexible tool that allows bug administrators to modify the bug tracking application to more closely model their own process. In this section, we highlight the major features of the bug tracking application. In Appendix 1, we demonstrate the power behind the CASEVision/Tracker tool, and show how quickly users can model their own process.

The primary goals of the CASEVision/Tracker tool are listed in order of importance:

The CASEVision/Tracker tool supports many generic facilities such as a graphic user interface (GUI) and a query and data manipulation language (DML). Refer to Appendix 1 for more details.

CASEVision/Tracker features described here can be implemented using CASEVision/ Tracker 2.0.

Overview

The CASEVision/Tracker tool manages bug reports and enhancement requests from submittal to resolution: Examples of applications at SGI

Integration with Configuration Management

This section describes the integration of Atria Software's ClearCase configuration management system with Silicon Graphics Inc.'s Tracker bug-tracking tools. The ClearCase/Tracker Integration provides each application with tools for exchanging information about bugs and bug-fixing activity. It updates the Tracker database automatically, and provides reporting capabilities for both the ClearCase and Tracker user.

The checkout/checkin Model

The checkout/checkin model is ClearCase's standard mechanism for managing the growth of an element's version tree: checkout creates an editable copy of a file in a user's view; checkin adds a new version to the element's version tree. The ClearCase/Tracker Integration extends this model to include information about bug fixing. When checking out a file, a developer enters a bug number. The checkout succeeds only if the bug number can be validated against an existing Tracker bug report. Information about the checkout is recorded in a ClearCase versioned object base, or VOB, in the form of an event record and attributes (see Figure 11). In the Tracker database, the update appears in the Resolved in: field.

FIGURE 11. Updating ClearCase and Tracker Databases When checking in a file, a developer enters a bug number again. This begins the same validation sequence that was performed before: the checkin succeeds only if a corresponding Tracker bug report exists. Both the VOB database and Tracker database are updated to reflect the file's change in condition.

Not every checkin constitutes a "fix", however. The developer can create "checkpoint" (intermediate) versions of a source file during the course of bug-fixing work. Only the final version "fixes" the bug, not the intermediate versions.

A developer can also cancel a checkout with the uncheckout command, removing information about the checkout from both the VOB database and Tracker database.

The integration does not impose a hard connection between a ClearCase checkin (a state transition) and a "fixed bug" (a status). It includes tools to create a closer connection, but the decision to call a bug "fixed" remains a site policy decision.

Using the Reporting Capabilities

Once a bug report is created, a Tracker user can recover the ClearCase-related information using standard Tracker procedures.They allow standard Tracker queries on any field.

The integration also provides ClearCase users with tools for tracking status:

      % find_fixes base.c
      Version base.c@@/main/5 fixes the following bugs:
      23 6 3

Notifications

CASEVision/Tracker uses electronic mail facilities to provide notifications of report events such as state transitions and overdue reports. In general, whenever a report is modified, the users listed in the Interested_parties field, the owner, and the submitter are all notified. Other notifications occur when a predetermined point in time is reached. These include notifying all concerned when a report has past its due date and is still open, and when the Reopen_date is reached for a deferred report.