Note:
The Reported Defects page displays the information in a Defects list. See Defects Page.
Starting from a single model version revision, you can see the defects that are directly reported against that revision on the Reported Defects page. The Reported Defects page is useful for assessing how progress is being made on defects directly reported against a released model version hierarchy, but may not be useful for understanding whether other model version revisions in a model version hierarchy are affected by any open issues. The Reported Defects page can show you, for example, that a defect was reported against CPU revision A and has not yet been closed out on all branches (or was closed with waivers), but it does not show you that a defect was created against CPU revision XYZ, which actually affects CPU revision A, because the defect was determined to have been introduced in CPU revision A. ExampleA defect is created as Reported Against a revision of model version CHIP. A defect action is created for this defect and is committed for model version ALU, which is in the CHIP model version hierarchy. In this case, from the perspective of the CHIP, the defect has been created, but there are no defect actions set up to resolve it. This means that the defect is not reported as affecting any revision of CHIP—as if the defect had not yet been triaged against that model version. The defect action is considered to affect only the revision of the ALU model version that it is committed against. This is reasonable, as it is the job of triaging to clean up such cases. In this instance, ALU is a sub-module of CHIP and the Introduced In revision should have been set to a revision of ALU. An Affecting Defects report for the CHIP revision would list this defect, but the Reported Defects page does not, since it affects one of the sub-modules used by CHIP and not the CHIP model version directly. | |||||||||||