From Fedora Project Wiki

(update the text that defines when blocker review meetings take place to match current practice (every monday, so long as there's at least one proposed blocker))
m (make keywords better readable)
 
(3 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>. 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.
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.