PCR field definitions are customized within /var/www/bugzilla/template/en/default/page/fields.html.tmpl. For additional guidance on filling out the fields, refer to the Problem reporting howto.
The Status and Resolution fields define and track the life cycle of a PCR.
STATUS |
RESOLUTION |
| The Status field indicates the current state of a PCR. Only certain status transitions are allowed, as defined by the PCR Status Workflow on Bugzilla's Administration page. | The Resolution field indicates what happened to this PCR. |
| Open PCRs | |
|
PCRs in one of these "open" states do not have a resolution yet. |
|
|
Newly created PCRs have an Initial State of NEW. Changing the Status to ASSIGNED is generally performed during a CCB meeting (CCB1 activity), and requires management approval, unless the Impact Assessment is Trivial.
Detailed description of the change or problem. Refer to the PCR writing guidelines and the Comment section below for help. The description must not reference customers or projects by name; instead, use code names or 3-digit customer numbers.
Recommendations: refrain from alarmist statements; stick to the facts; do not include email chains, and instead, create an attachment.
Flags are used to indicate status of configuration items, i.e., Requirements, Code, Test Cases, and Test Procedures. When a component/project enters the verification phase, the user must follow the review process game when performing verification reviews. Process Note: PCR numbers are required for all CM commits against lifecycle data items, along with updates to the appropriate Status File.
Definition of flag values:
| Space | : | Assessment is needed. |
|---|---|---|
| ? | : | The Requestee (user listed to the right of the Flag) will perform an assessment of required changes and/or make those changes. If Requestee is blank (as this field is optional), the Requester (a.k.a. Flag_Setter) is most likely the Maintainer performing the assessment. |
| + | : | Required changes have been committed to CM (i.e., changes to this configuration item type are "Closed"). The user listed to the left of the Flag is the Maintainer who set the flag to "+" (a.k.a. the Requester or Flag_Setter); however, the Requester is not necessarily the Maintainter who performed the work. The CM log identifies the Maintainer(s) who performed the work, as described in the configuration-management-howto. |
| - | : | Assessment was performed, and no changes are required. |
When the last remaining Flag is changed to "+" or "-" (i.e., all the other Flags have been set to "+" or "-") the PCR Status must be changed to RESOLVED, or a Comment added as to why the PCR is left Open. Changing a Flag or Status triggers assessment of the PCR by CCB (CCB3 activity).
Once Status has been updated to FIXED, but before CCB updates it to CLOSED, it is possible that an additional change/problem is identified. E.g., while performing tests, a problem is discovered with the recent code changes. In this case, the Code flag must be updated from "+" to "?", the Flag_Requestee assigned to the responsible Maintainer, and the Status updated to ASSIGNED.
Once Status is set to CLOSED, no changes should be made to any artifacts; however, additional Comments may be added.
Prior to CCB updating the Status to CLOSED, it is acceptable for a "+" to be changed to a "?" if subsequent activity uncovers a problem; e.g., a tester might change the Code flag from "+" to "?" if a problem is uncovered during testing. In this scenario, the tester should re-assign the PCR to the code author to generate notification that additional work is required.
To search for PCRs by Requestee, use the My Requests link in the page footer, and update the query appropriately. Or, use the search page and specify a Flag value; e.g., specifiy Code+ to see all PCRs which are "code complete". This example is a search for all PCRs neither closed nor "none required", i.e., neither "+" nor "-".
The developer performing an assessment of required changes and/or making the changes to the specified configuration item type; must be set to a valid Bugzilla user. Bugzilla will auto-complete email addresses, e.g., when "md" is entered, Bugzilla will fill in "mdiethelm@ddci.com". Each configuration item type may have a different Requestee. The PCR Assignee should be updated to each Requestee as the PCR moves through the lifecycle for each configuration item.
If the PCR is actively being worked, then the Assignee should be one of the names included in (one of) the Flag having a '?'.
One thing to note is that Bugzilla does "autolinkification" of several things. What this means is that you can type most forms of URLs (e.g., http:...) and when the text is displayed to the user, Bugzilla will generate a "hotlink" to the destination of the URL. General http, https, mailto, and several other general URLs are supported. In addition, Bugzilla will generate a "hotlink" if you specify PCR nnn in your text. The hotlink will be struck through if the PCR has been resolved, and will have a "tooltip" containing the Resolution and the Summary of the PCR. You can even make a reference to a specific comment by either specifying, for example: "PCR 1 comment 2", or from one comment to another comment in the same PCR by just using "comment ccc", e.g., "see comment 2 above".
To interface with Subversion, you can also put "SVNRevision nnnn", or "SVNRevision(repositoryName) nnnn" and a link to that revision in the given repository will be constructed. If no "repositoryName" is specified, then a default of "Deos" is assumed for the shared IP Bugzilla and "DDCI" for the DDCI Bugzilla.
To support legacy PCRs imported from Track, the shared IP autolinkification has been extended to support several variants of the PCR A-nnn, and PCR E-nnn formats. Note however that you SHOULD NOT use the "A-" or "E-" syntax for new PCRs.
Note that you can have Bugzilla autolinkify any text you'd like (e.g., to send in an email, or post on the web) by visiting the autolinkify page.
Note: When searching, selecting the option "All" does not select PCRs assigned against any platform. It merely selects PCRs that are marked as occurring on all platforms, i.e. are designated "All".
Note: When searching, selecting the option "All" only finds PCRs whose value for this field is literally the word "All".TBD
Default value. The PCR cannot be Assigned and CM commits are not allowed when Priority is set to TBD.
Next Release
The PCR must be resolved before the next release is made. Valid for all DO-178C Classifications.
Any Upcoming
An opportunistic PCR that can be resolved in any future release, even beyond the next certification release. Valid for all DO-178C Classifications.
By Cert
The PCR must be resolved before the next certification release is made. Note that if the next release is a certification release, then Next Release and By Cert are equivalent, but By Cert should be selected. Valid for DO-178C Classifications DAL-A through D and TQL-4.
Hold
The PCR should not be worked, and CM commits are not allowed. User should add justification within a comment with justification for setting Priority to Hold. Valid for all DO-178C Classifications.
Note that in most DDC-I documentation the phrase "component" is used to refer to either or both a Bugzilla Product or Bugzilla component. This confusion is regrettable, but not really significant.
Select a Classification to narrow down this list.You should normally use this field to refer to PCRs in other installations. For PCRs in this installation, it is better to use the Depends on and Blocks fields.
TBD
Default value. Before the PCR Status can be updated to ASSIGNED, a valid Severity must be selected.
An error in lifecycle data which does not impact system safety; within this context, defects are not visible to the user. Defects that cannot be resolved via additional analysis become Limitations. Valid for all DO-178C Classifications.
The documented desire for a new feature or the extension of an existing feature. An enhancement could also include the desire to change something in order to make a verification step easier. Valid for all DO-178C Classifications.
Executable object code does not meet requirements or user's guide. For DO-178C Classification DAL-A through D, a Limitation may impact the system safety. PCRs with this Severity must have an accompanying work-around documented in the SAS to provide a mitigation strategy. This value is not valid for Components with DO-178C Classification of UDT or PPP.
A documented process or procedure was not followed. If the non-compliance was found during an audit, then the URL field should contain the Audit ID (e.g., 2005-007) for the audit results which document the non-compliance. If the non-compliance was found some other way, then the means of detection should be documented in a comment.
A cosmetic deficiency in a life-cycle data item or a configuration item change is needed as a result of an administrative action. Examples include correcting typos, "create Software Accomplishment Summary," and "merge code to mainline". Valid for all DO-178C Classifications.
This selection list contains the names of the current branches. TBD should be used if the Reporter is unsure which branch the configuration item(s) reside upon. Note that no configuration item change can take place under this PCR while the branch is TBD (i.e. the branch must be determined before any CM activity can be performed).