Pegasus Enhancement Proposal (PEP)

PEP #: 002

Title: Pegasus Bug Tracking and Bug Fix Commitment Process

Version: 2.8

Created: 10/22/02

Authors: Warren Grunbok
Roger Kumpf

Status: draft

Version History:

Version	Date	Author	Comments
1.0	November 2002	Mike Day	Initial submission
1.1	Tue Jan 7 10:07:16 2003	Mike Day	Incorporating comments from Steering Committee
1.2	Thu Jan 16 09:19:50 2003	Mike Day	Incorporating second round of comments from Steering Committee
1.3	10/30/03	Warren Grunbok	Limit to discussion of bugzilla usage in context of Core and non-Core.
1.4	12/12/03	Warren Grunbok	Update to include comments to 1.3 rewrite
1.5	1/14/04	Warren Grunbok	Update to reflect "Core" vs Kernel concept.
1.6	02/03/04	Warren Grunbok	Update to reflect bug - Fix relationship
1.7	2/6/04	Warren Grunbok	Update "Core" file section Cleaned up extraneous tags Used Orange to show new updates in this version
1.8	2/18/04	Warren Gunbok	Added Bugzilla "enhancement" type review as per input from Roger Kumpf, corrected kernel file -> inspected files
1.9	3/1/04	Warren Grunbok/ Dan Gorey	-Added Committing fixes section -Made the Commit message section more specific -Added Commit Procedure section - Added member of community review in reviewing the fix section - Added wish for automated commit messages to discussion section.
2.0	3/9/04	Warren Grunbok	- Added problem reproduction suggestions to creating a bug report section - Moved Reviewing a proposed fix section - reworded committing a fix section - made testing considerations consistant with PEP 001 - commit procedure and commit message sections now reflext the automated commit messages Note version 1.10 didn't have this section filled out. I decided to rename 2.0, as that ordered this PEP better on the PEP list page.
2.1	3/23/04	Warren Grunbok	- Removed "The CVS Commit message" Put the section in PEP 108. - Minor updates to "Proposing a Fix" section - Changed wording in "Reviewing a Proposed Fix" on interface breakage wording - Changed wording in "Committing a Fix" section to remove "once a fix has been made"
2.2	5/21/04	Warren Grunbok	Minor changes to accomodate minor comments...removed "Word" induced extra tags
2.3	7/21/04	Warren Grunbok Update based on extensive comments by Roger Kumpf
2.4	8/06/04	Warren Grunbok	Changes to improve document flow and resolve Discussion issues from previous version
2.5	09/16/04	Warren Grunbok	Added non-fix resolution, removed duplicate MUST process section, clarified acceptance time, Added Closing a bug section and commiting a fix
2.6	9/31/04	Warren Grunbok	Minor revision to remove redundance in Accepting the bug, changed Linux to Unix for required test platforms.
2.7	10/05/04	Martin Kirk/Warren Grunbok	Reworded testing considerations section.
2.8	10/15/04	Roger Kumpf/Warren Grunbok	Another rewording of testing considerations sections

Abstract:

This PEP proposes a standard method for creating, tracking, proposing fixes, and fixing Pegasus defects.

The PEP will propose a process for reviewing bugs and their associated fixes, the requirements for when a fix must be reviewed, and the approval process for committing the fix.

External Interfaces: NA

Definition of the Problem:

The OpenPegasus project has a need to define a process by which defects are managed. Through use of Bugzilla, defects are tracked, managed, and when code changes are required, a Bugzilla Bug must be associated with those changes. All defect and fix level changes to OpenPegasus CVS must be tracked through the Bugzilla system, and minor enhancements MAY be tracked through Bugzilla. This PEP will define those processes.

Proposed Required Processes Changes:

This section will hilight all required points of this process. These statements are included within the document below.

All defect and fix level changes to OpenPegasus CVS must be tracked through the Bugzilla system.
All submissions to OpenPegasus CVS must abide by all agreements for contribution set forth by the OpenPegasus Steering Committee.
Bugzilla records meeting any of the following criteria must be reviewed by the Pegasus Architecture Team prior to submission of a proposed fix:

The severity is set to 'enhancement'.

The proposed fix affects an externally supported interface or an associated .h file. Refer to PEP 184 for a description of OpenPegasus external interfaces.

The proposed fix has a significant adverse impact on Pegasus functionality, performance, localizability, security, usability, reliability, scalability, supportability, or maintenance.

The defect owner requests a review.

A member of the community requests a review.

Involves changes to at least one Inspected File.

A fix must be reviewed and approved by the Architecture committee prior to commit of inspected files.

Reporting a Bug

To report a problem an individual must create bug in the TOG Bugzilla database.

Individuals must create and use their own login accounts in order to submit a bug. If the OpenPegasus community has any questions about the bug this will provide a contact. In addition, if there is a proposed fix, the community must know the source of the proposal.

A given bugzilla bug report is release specific. The release field in bugzilla is intended to show the release that the bug was reported against, and the release in which the fix needs to be made. If a bug occurs in additional releases, a separate bugzilla would need to be written for each release that a developer deems necessary. There is not necessarily a 1 to 1 mapping of fixes to bugs. The release definition PEP may list release specific exceptions.

For each bug created, the following needs to be entered so as to allow the development community to prioritize bugs:

Priority: Used to classify bugs by how important they are to be fixed in the specified release. This can be set and reset by the platform advocates, during bug calls or by arch team.
Severity: When/If encountered, determines the impact of the bug. This should be set by the submitter of the bug. The Architecture team may also adjust the severity of a bug. The forum for this is the weekly bug call.

The bugzilla should indicate how the problem is reproduced. Some examples are:

List of test cases run that originally exibited the bug etc...
Relevant conditions of the test such as machine load, number of processors etc...
Build parameters
Environment variables for test

Assigning the Bug

Bugzilla requires assignment of a bug record upon creation. It will be assigned to a special account unassigned@openpegasus.org until such time as the bug is assigned to a particular developer.

Bugs become assigned to a developer either by assigning the bug to themself or by being assigned the bug in the bug call .

The tenant (if one exists) of a source module has the responsibility of taking assignment of bugs while the file is “checked out” to that developer. See PEP 108 for discussion of tenants and CVS procedures for details on module check out.

Accepting/Rejecting the Bug

It is the responsibility of a developer who has been assigned a bug to accept, reject, or reassign that bug within 1 week. The bug is accepted by changing the status to 'ASSIGNED'. The bug is rejected by changing the owner to another developer or to 'Unassigned'.

Once a bug record has been accepted by a developer, that developer should strive to fix or reassign the bug within the following time periods:

Severity	Bug /fix goal
Blocker	24 hrs.
Critical	48 hrs.
Major	1 week
Normal, Trivial, Enhancement , and Minor	2 Months

Inaction by the owner of the bug may cause a reassignment of the bug record.

When a developer accepts a bug, the developer accepts the responsibility to fix, test, then commit the fix to CVS in the release stated in the bugzilla. In cases where there are no code changes, the developer who accepts the bug, accepts the responsibility to resolve the bug.

Bugs may be rejected and not fixed should the developer feel a fix is inappropriate. This position must be justified in the bug record.
The tenant (if one exists) of a source module has the responsibility of accepting or responding to bugs while the file is “checked out” to that developer. See PEP 108 for discussion of tenants and CVS procedures for details on module check out.

Proposing a Fix

Any person with a bugzilla account may propose a fix to a bug at any time by attaching a source code patch to a bug record.

The submitter of the proposed fix should document the "release fixed in" as part of the proposed fix in the bug.

Reviewing a Proposed Fix

A Bug meeting any of the following criteria must be reviewed and approved by the Pegasus Architecture Team prior to submission of a proposed fix:

The severity is set to 'enhancement'.
The proposed fix affects an externally supported interface or an associated .h file. Refer to PEP 184 for a description of OpenPegasus external interfaces.
The proposed fix has a significant adverse impact on Pegasus functionality, performance, localizability, security, usability, reliability, scalability, supportability, or maintenance.
The defect owner requests a review.
A member of the community requests a review.
The fix involves changes to at least one Inspected File.

In the case where the bug must be reviewed, the Bug will be annotated with the date of the Pegasus Architecture Teleconference in which the proposed fix will be discussed. The results of the discussion (including approval status) will be subsequently appended to the bug by the meeting moderator. In the case of an 'enhancement' Bug, a possible result is that a PEP is necessary to complete the approval process.

Committing a Fix

After the necessary code changes have been made and approvals (if needed) for the changes completed, the code can be checked in.
A developer must have the proper permissions to the CVS repository. If not, email pegasus-admin@openpegasus.org as a generic address for contact.
(See PEP 108 for complete description of CVS procedures.) Developers must not update a file that is locked by a tenant.

Closing a bug

The state of a bug must be placed into the RESOLVED/FIXED state once all changes are made that resolve the problem stated in the bug. If a partial fix is performed, the developer should indicate what was fixed in the bug, and return the bug to UNASSIGNED if there will be no further changes made by that developer. Placing the bug into the resolved/fixed indicates that ALL code changes required to fix the problem have been made and the updated files placed into CVS. Once the fix has been verified or the community agrees with the fix, the bug should be updated to reflect a CLOSED status following any of the following events:

Verification of fix by the reporter of the bug.
Architecture Committee review and recommendation.

This PEP recommends that once per release all bugs that remain in the fixed state be reviewed by the Architecture Committee for closure. All bugs deemed acceptable must be changed to the closed state.

Should a developer decide no change is needed, a bug may be resolved by changing the resolution field of the bug to one of the following:

WONTFIX - if the developer does not feel a fix is appropriate
INVALID - if the bug is not indicative of a Pegasus defect
DUPLICATE - if the bug is captured in another bug record
WORKSFORME - if the bug cannot be reproduced or otherwise detected. The rationale must be documented in the bug record.

Testing considerations

The bug should indicate what additional testing or additions to the test suite should be made if appropriate.
Regardless of the etiology of any change to any OpenPegasus CVS file, or group of files, the change:
1) must not break the Pegasus build
2) must not break the automated Pegasus test cases.
The OpenPegasus community's expectations with respect to build and test of new and modified code are: 1) the source must build and pass all regression tests on at least one supported platform (developer's choice) and 2) the source additionally should be tested on either Linux or Windows.
Changes should not be submitted if they are known to break the build or the automated testing process on ANY platform.

Rationale

Most of what's documented here comes from what has worked well over the past few years, and what has not. This version of the PEP is derrived from many comments and discussions in the Architecture Committee, that resulted in an efficient process and one that would allow the project to track changes to the code base.

Schedule

The goal is to have this PEP approved prior to the Pegasus 2.4 cycle completion.

action	planned	actual	Comment
PEP submitted	11/19/2003	11/19/03
PEP reviewed	12/19/2003	08/02/04	Last review date reflected here.
PEP approved	08/30/04
Code committed	n/a	n/a	(This is a process PEP -- has no associated code.

References:

For more CVS commands and help see the CVS book by Fogel & Bar, 2nd edition. It can be found in http://cvsbook.red-bean.com/.

Or the cederquist book which is the real manual and is at http://www.cvshome.org/docs/manual/cvs-1.11.13/cvs. html#SEC_Top

Discussion

Copyright (c) 2004 EMC Corporation; Hewlett-Packard Development Company, L.P.; IBM Corp.; The Open Group; VERITAS Software Corporation

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

THE ABOVE COPYRIGHT NOTICE AND THIS PERMISSION NOTICE SHALL BE INCLUDED IN ALL COPIES OR SUBSTANTIAL PORTIONS OF THE SOFTWARE. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Template last modified: July 6, 2004 by Denise Eckstein
Template version: 1.10