1. Summary
  2. Files
  3. Support
  4. Report Spam
  5. Create account
  6. Log in

Reporting Issues

From tianocore

Jump to: navigation, search

The SourceForge Trac Application

The bug tracking system used by the EFI and Framework Open Source Community Website is "Project Tracker". The application allows for each project to have its own database for "artifacts" (defects, enhancements, tasks). The application is highly configurable, and for the EFI and Framework Open Source Community Website has been configured to support the unique need for a tightly controlled process of changing the codebase. The purpose of this page is to provide the EFI and Framework Open Source Community Website users with an understanding of the configuration of Project Tracker for this site. If you need more help to understand the underlying tool please consult the help documentation on that topic.

Concept Check: Domain vs Project Configuration

Project Tracker has two levels of configuration: Domain and Project. The Domain settings establish the artifact types to be used (in this case we use Defect, Enhancement and Task). Also at the domain are rules for the attributes for each artifact (i.e., Defect consist of Description, Severity, Priority, etc), and the values those attributes hold (i.e. Priority can be high, medium, low). Some of these settings are "editable" at the project level, some are not. The goal is to provide each project manager the ability to control changes to their code as they see fit, while maintaining some level of consistency throughout the site.

Concept Check: "Ownership" vs "Association"

Project Tracker approaches artifacts in a somewhat unique manner. Instead of having an "owner" of a defect, enhancement, etc., the tool assumes a person is simply "associated" with the artifact in some manner. This is more reflective of real life. As an example, a defect is "owned" by several people throughout its life, so most tools simply change owners to show the issue flowing through the process. This effectively removes responsibility from previous owners, putting the onus on the current owner to decide where to send the issue. Project Tracker's "Associations" remove this problem. If a person is associated with a defect as the "Resolver", then they remain connected with this issue throughout its life. They work on it depending on the "Status" of the issue, not on the ownership. This way there are multiple shephards of a defect, not just one. It also allows for maximum visibility into issues, ensuring the fix that makes its way back into the code is solid.

The EFI and Framework Open Source Community Website Configuration

As mentioned above, the EFI and Framework Open Source Community Website has three artifacts established: Defect, Enhancement and Task. For each of these there are a number of attributes (i.e, fields), and associations (who acts upon it). The following tables describe the settings for these artifacts for the EFI and Framework Open Source Community Website, both at the Domain level as well as how they are used in the EDK project. For new projects on the site, their managers will have these attributes and associations at their disposal to craft their own defect management process, optimizing and and streamlining as they see fit.

The following diagrams show the general flow of the Defects, Enhancements and Tasks in a typical EFI and Framework open source project:


DEFECT File:HiLevelDefectProcess.gif
ENHANCEMENT File:HiLevelEnhancementProcess.gif
TASK File:HiLevelTaskProcess.gif



The following tables summarize how Project Tracker is configured on the EFI and Framework Open Source Community Website. Each table tells you five things:

1.What are the artifacts that the EFI and Framework Open Source Community Website has defined for use by projects hosted here? 2.What are the attributes of each artifact that are available for each project to use? 3.What attributes are being used by the main EDK project? 4.What are the associations being used to manage how attributes move through their lifespan? 5.What associations are being used by the main EDK project? To see the default process flow for a DEFECT (which is also the flow for the EDK Project's DEFECT), go here.

Artifact 1 - DEFECT
Attribute Name Used in EDK Project? Attribute Description
Summary * The major part of the code base that the bug affects
Component * (changed
to "Module")
The major part of the code base that the bug affects
Sub-component The minor part of the code base that the bug affect
Platform The particular platform the bug was found on
Operating System The particular operating system the bug was found on
Description * A detailed description of the bug, including steps to recreate
(screenshots, code snippets, etc are attached to the Defect at this stage)
Severity The impact of the defect to the usability of the code
Found in Build _____ * In which build the defect was found (number or date)
Tracking Attributes
Defect Status * What stage the defect is at in its resolution process
Artifact Priority * What priority the bug has to the resolver
Difficulty * How difficult it is to fix the bug
Effort Estimate * How long it is estimated to fix the bug
Effort Fix Date * Self-explanatory
Milestone * For projects using a milestone strategy, which milestone is the fix being targeted for (ex. June Release)
Target Major/Minor Release * For projects using a release strategy, which X.Y Release is the fix being targeted for (ex. 3.1)
Target Maintenance Release * Used in conjunction with the above attribute to further describe a release number (ex. 3.1.2)
Target Patch Number * Used in conjunction with the above attribute to further describe a release number (ex. 3.1.2.147)
Target Iteration Number For projects doing iterative-style development, which iteration is the fix being targeted for
Resolution Attributes
Defect Resolution * What was the resolution of the defect
Resolution Description * Description of the resolution ("diff" file is attached to the Defect at this stage)
Association Used in EDK Project? Description
Issue Submitter * This is the individual that submits a defect (system-defined association)
Maintainer * The person responsible for the overall coding effort for a component, module, functional area, etc.
Issue Screener * The person who screens new issues to make sure they are defects
Resolver * The person who fixes a bug
Fix Reviewer * The person who reviews a fix for proper coding standards
Integrator * The person who integrates the changes back into the code repository
Verifier * The person who verifies that the code change did indeed fix the defect
Interested Party * Any person who wants to be informed of the resolution of a particular defect


Artifact 2 - ENHANCEMENT
Attribute Name Used in EDK Project? Attribute Description
Request Information Attributes
Summary * Brief summary of the enhancement request
Justification * A brief description of why this enhancement is a good idea
Description * A detailed description of the enhancement request (attaching supporting information such as tech spec, pseudo-code, etc)
Component *
(changed to "module")
The major part of the code base that the enhancement affects
Sub-component The minor part of the code base that the enhancement affects
New Featureset? * If this enhancement is not related to an existing bundle of enhancements or general enhancement group, it is a new featureset.
This field is used when there are many new features to be managed.
Parent Featureset ID * If this enhancement is related to an existing bundle of enhancements or general enhancement group, that number goes here.
This field is used when there are many new features to be managed.
Tracking Attributes
Enhancement Status * This field controls the stages of an enhancement.
Artifact Priority * What priority the enhancement has for the person implementing it
Effort Estimate * What is the effort to implement this enhancement
Milestone * For projects using a milestone strategy, which milestone is the enhancement being targeted for (ex. June Release)
Target Major/Minor Release * For projects using a release strategy, which X.Y Release is the enhancement being targeted for (ex. 3.1)
Target Maintenance Release * Used in conjunction with the above attribute to further describe a release number (ex. 3.1.2)
Target Patch Number * Used in conjunction with the above attribute to further describe a release number (ex. 3.1.2.147)
Target Iteration Number For projects doing iterative-style development, which iteration is the enhancement being targeted for
Resolution Description * Description of the resolution ("diff" file is attached to the Enhancement at this stage)
Association Used in EDK Project? Description
Issue Submitter * This is the individual that submits an enhancement request (system-defined association)
Maintainer * The person responsible for the overall coding effort for a component, module, functional area, etc.
Issue Screener * The person who screens new enhancement requests and determines what to do with it.
Resolver * The person who implements the coding changes for the enhancement.
Fix Reviewer * The person who reviews code changes for proper coding standards
Integrator * The person who integrates the changes back into the code repository
Verifier * The person who verifies that the code change supported the intended enhancement
Interested Party * Any person who wants to be informed of the resolution of a particular enhancement request


Artifact 3 - TASK
Attribute Name Used in EDK Project? Attribute Description
Task Information Attributes
Summary * Brief summary of the task to be performed
Description * A description of the task
Effort Estimate * What is the effort to complete this task
Tracking Attributes
Task Status * This field controls the stages of a task
Artifact Priority * What is the priority of this task for the person completing it
Milestone * For projects using a milestone strategy, what is the milestone that this task should be completed by
% Complete * Self-explanatory
Progress Notes * Self-explanatory
Estimated Completion Date * Self-explanatory
Actual Completion Date * Self-explanatory
Task Completion Notes * Self-explanatory
Association Used in EDK Project? Description
Task Initiator * This is the individual that submits an enhancement request (system-defined association)
Assigned To * The person responsible for the overall coding effort for a component, module, functional area, etc.
Progress Tracker * The person who screens new enhancement requests and determines what to do with it.
Personal tools