Reporting Issues - tianocorecn/tianocorecn.github.io GitHub Wiki
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.
| Attribute Name | Used in EDK Project? | Attribute Description |
|---|---|---|
| Summary |
|
The major part of the code base that the bug affects |
| Component |
|
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 |
| 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 |
|
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 |
| 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. |