From Fedora Project Wiki

(use {{code}} instead of <code> consistently)
m (make keywords better readable)
 
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}}}}}{{#ifeq:{{{type|}}}|blocker|, {{code|Accepted0Day}} or {{code|AcceptedPreviousRelease}} (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}}}}} 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.
+
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.
This template is used to share very similar content between the QA:SOP_blocker_bug_process and the QA:SOP_freeze_exception_bug_process, for efficiency and consistency.

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.