(create template for another shared section of the blocker/FE processes) |
(fix some spacing issues in the ifeqs) |
||
| Line 2: | Line 2: | ||
== Tracking {{{type|$TYPE}}} bugs == | == Tracking {{{type|$TYPE}}} bugs == | ||
Again, tracking {{{type|$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 {{{type|$TYPE}}}s and ensuring that the appropriate resources to fix them are in place, as well as evaluating proposed {{{type|$TYPE}}}s. {{#ifeq:{{PAGENAME}}|SOP freeze exception bug process|After blocker bugs, |}}QA group members are encouraged to prioritize testing of {{{type|$TYPE}}} bug fixes, development group members are encouraged to prioritize developing fixes for {{{type|$TYPE}}} bugs, and release engineering group members are encouraged to prioritize the release of fixes for {{{type|$TYPE}}} bugs (after appropriate testing). Each group should have its own processes for ensuring its responsibilities in relation to {{{type|$TYPE}}} bugs are met. | Again, tracking {{{type|$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 {{{type|$TYPE}}}s and ensuring that the appropriate resources to fix them are in place, as well as evaluating proposed {{{type|$TYPE}}}s.{{#ifeq:{{PAGENAME}}|SOP freeze exception bug process|After blocker bugs,|}} QA group members are encouraged to prioritize testing of {{{type|$TYPE}}} bug fixes, development group members are encouraged to prioritize developing fixes for {{{type|$TYPE}}} bugs, and release engineering group members are encouraged to prioritize the release of fixes for {{{type|$TYPE}}} bugs (after appropriate testing). Each group should have its own processes for ensuring its responsibilities in relation to {{{type|$TYPE}}} bugs are met. | ||
In Bugzilla, {{{type|$TYPE}}} bugs should follow the normal [[BugZappers/BugStatusWorkFlow|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. {{#ifeq:{{PAGENAME}}|SOP freeze exception bug process|Builds that fix freeze exception bugs should be pulled into TC and RC builds by the release engineering team as long as they are submitted as proposed updates and meet the necessary karma requirements. |}}No {{{type|$TYPE}}} bug should be set to '''CLOSED ERRATA''' until a fix is actually released to the stable repository for the release in question: if a working fix is added to a test candidate or release candidate 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. | In Bugzilla, {{{type|$TYPE}}} bugs should follow the normal [[BugZappers/BugStatusWorkFlow|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.{{#ifeq:{{PAGENAME}}|SOP freeze exception bug process| Builds that fix freeze exception bugs should be pulled into TC and RC builds by the release engineering team as long as they are submitted as proposed updates and meet the necessary karma requirements.|}} No {{{type|$TYPE}}} bug should be set to '''CLOSED ERRATA''' until a fix is actually released to the stable repository for the release in question: if a working fix is added to a test candidate or release candidate 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. | ||
<noinclude>[[Category:QA_Blocker_freeze_exception_templates]]</noinclude> | <noinclude>[[Category:QA_Blocker_freeze_exception_templates]]</noinclude> | ||
Revision as of 21:30, 24 September 2014
Template documentation [edit]
- This documentation is transcluded from Template:Blocker freeze exception tracking/doc. It will not be transcluded on pages that use this template.
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: if a working fix is added to a test candidate or release candidate 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.