Tracking $TYPE bugs
Again, tracking $TYPE bugs and ensuring that they are fixed is a collaborative effort between the QA, Development and Release Engineering groups. The QA:SOP_Blocker_Bug_Meeting process includes reviewing the status of existing $TYPEs and ensuring that the appropriate resources to fix them are in place, as well as evaluating proposed $TYPEs. QA group members are encouraged to prioritize testing of $TYPE bug fixes, development group members are encouraged to prioritize developing fixes for $TYPE bugs, and release engineering group members are encouraged to prioritize the release of fixes for $TYPE bugs (after appropriate testing). Each group should have its own processes for ensuring its responsibilities in relation to $TYPE bugs are met.
In Bugzilla, $TYPE bugs should follow the normal workflow, with special attention paid by the development group to submitting proposed fixes to the updates-testing repository so they reach MODIFIED and ON_QA status, and special attention paid by the QA group to testing proposed fixes and setting ones that are tested successfully to the VERIFIED status. No $TYPE bug should be set to CLOSED ERRATA until a fix is actually released to the stable repository for the release in question and also included in an RC compose (if it is related to a package from such a package set). If a working fix is added to a TC or RC build, but not yet pushed to the stable repository, the bug should not be marked CLOSED ERRATA, as this may result in the fix not being pushed to the stable repository and the fix accidentally omitted from the next candidate build as it is no longer possible to track the bug.