(adjust for non-image blocker process changes, as discussed on test@ - https://lists.fedoraproject.org/archives/list/test%40lists.fedoraproject.org/thread/H35Q7UQZBZWYSQM3GHCE6VPK3N6PATIO/) |
m (make keywords better readable) |
||
| (2 intermediate revisions by one other user not shown) | |||
| Line 6: | Line 6: | ||
When appropriate, proposed {{{type|$TYPE}}}s may also be reviewed between meetings by Bugzilla comment discussion, or during the [[Go_No_Go_Meeting|''engineering readiness meeting'']] (also known as a ''go/no-go meeting'') which is convened to decide whether a release candidate should be approved as a final release. In these cases, consensus between the three stakeholder groups should still be reached in order to accept or reject a bug as a {{{type|$TYPE}}}. However, review should not be done as part of [[QA/Meetings|QA meetings]]. If {{{type|$TYPE}}} review is required or desirable at the time of a QA meeting, a proper {{{type|$TYPE}}} bug review meeting should be convened immediately following the QA meeting. {{#ifeq:{{PAGENAME}}|SOP freeze exception bug process| |Bugs which are rejected as {{{type|$TYPE}}}s can be considered for the [[QA:SOP_freeze_exception_bug_process|freeze exception bug process]].}} | When appropriate, proposed {{{type|$TYPE}}}s may also be reviewed between meetings by Bugzilla comment discussion, or during the [[Go_No_Go_Meeting|''engineering readiness meeting'']] (also known as a ''go/no-go meeting'') which is convened to decide whether a release candidate should be approved as a final release. In these cases, consensus between the three stakeholder groups should still be reached in order to accept or reject a bug as a {{{type|$TYPE}}}. However, review should not be done as part of [[QA/Meetings|QA meetings]]. If {{{type|$TYPE}}} review is required or desirable at the time of a QA meeting, a proper {{{type|$TYPE}}} bug review meeting should be convened immediately following the QA meeting. {{#ifeq:{{PAGENAME}}|SOP freeze exception bug process| |Bugs which are rejected as {{{type|$TYPE}}}s can be considered for the [[QA:SOP_freeze_exception_bug_process|freeze exception bug process]].}} | ||
Bugs that are accepted as {{{type|$TYPE}}}s for the relevant release will be marked with the Whiteboard field <code>Accepted{{{typecamel|$TYPECAMEL}}}</code>{{#ifeq:{{type|}}|blocker|, | Bugs that are accepted as {{{type|$TYPE}}}s for the relevant release will be marked with the Whiteboard field <code>Accepted{{{typecamel|$TYPECAMEL}}}</code>{{#ifeq:{{{type|}}}|blocker|, <code>Accepted0Day</code> or <code>AcceptedPreviousRelease</code> (see below for details on these)|}}. Bugs which are rejected as {{{type|$TYPE}}}s will be updated to no longer block the relevant ''tracker bug'', and have the <code>Rejected{{{typecamel|$TYPECAMEL}}}</code> Whiteboard field added so that if they are proposed as {{{type|$TYPE}}}s again, it is clear they have already been considered and rejected. Therefore, a bug which has been proposed but not accepted or rejected can be identified by the lack of a relevant Whiteboard field. All changes to {{{type|$TYPE}}} status should also be documented with a comment. The comment should explain the rationale behind the decision and should link to the summary or logs of the meeting at which the decision was made. | ||
<noinclude>[[Category:QA_Blocker_freeze_exception_templates]]</noinclude> | <noinclude>[[Category:QA_Blocker_freeze_exception_templates]]</noinclude> | ||
Latest revision as of 10:10, 21 September 2020
Template documentation [edit]
- This documentation is transcluded from Template:Blocker freeze exception reviewing/doc. It will not be transcluded on pages that use this template.
Reviewing $TYPE bugs
Proposed $TYPEs are reviewed and either accepted or rejected as $TYPEs in collaboration between three stakeholder groups: QA, Development and ReleaseEngineering. This is mostly done during weekly meetings for the express purpose of reviewing blocker and freeze exception bugs: the procedure followed during these meetings is documented here. $TYPECAMEL review meetings usually occur every Monday - immediately after the QA meeting - so long as there is at least one proposed blocker, but special review meetings can be scheduled at other times when necessary. They are always announced to the test-announce mailing list, which is CC'ed to devel. The $TYPE review meetings are public, and reporters who propose a bug as a $TYPE are allowed and indeed encouraged to attend the meeting where it is reviewed.
When appropriate, proposed $TYPEs may also be reviewed between meetings by Bugzilla comment discussion, or during the engineering readiness meeting (also known as a go/no-go meeting) which is convened to decide whether a release candidate should be approved as a final release. In these cases, consensus between the three stakeholder groups should still be reached in order to accept or reject a bug as a $TYPE. However, review should not be done as part of QA meetings. If $TYPE review is required or desirable at the time of a QA meeting, a proper $TYPE bug review meeting should be convened immediately following the QA meeting. Bugs which are rejected as $TYPEs can be considered for the freeze exception bug process.
Bugs that are accepted as $TYPEs for the relevant release will be marked with the Whiteboard field Accepted$TYPECAMEL. Bugs which are rejected as $TYPEs will be updated to no longer block the relevant tracker bug, and have the Rejected$TYPECAMEL Whiteboard field added so that if they are proposed as $TYPEs again, it is clear they have already been considered and rejected. Therefore, a bug which has been proposed but not accepted or rejected can be identified by the lack of a relevant Whiteboard field. All changes to $TYPE status should also be documented with a comment. The comment should explain the rationale behind the decision and should link to the summary or logs of the meeting at which the decision was made.