From Fedora Project Wiki
(fork)
 
(change GOLD to GO)
(One intermediate revision by the same user not shown)
Line 3: Line 3:
Before each public release Development, QA, and Release Engineering meet to determine if the release criteria are met for a particular release.  This meeting is called the: '''Go/No-Go Meeting'''.  
Before each public release Development, QA, and Release Engineering meet to determine if the release criteria are met for a particular release.  This meeting is called the: '''Go/No-Go Meeting'''.  


Verifying that the Release criteria are met is the responsibility of the [[QA|QA Team]]. QA team's determination must be based on the [[QA:SOP_blocker_bug_process|blocker bug process]]. QA approves the release if all validation tests appropriate to the release phase (Alpha, Beta or Final) have been performed and there are no accepted blocker bugs that are unaddressed in the candidate compose. QA does not approve the release if there are any accepted blocker bugs that are unaddressed in the candidate compose or if validation testing is incomplete. There is no room for discretion in this determination. The Go/No-Go Meeting may serve as a blocker review meeting, if there are outstanding proposed blockers - as long as the necessary groups are present - in order to make the determination possible by deciding if they are accepted or rejected.
Verifying that the Release criteria are met is the responsibility of the [[QA|QA Team]]. QA team's determination must be based on the [[QA:SOP_blocker_bug_process|blocker bug process]]. QA approves the release if all validation tests appropriate to the release phase (Alpha, Beta or Final) have been performed and there are no accepted blocker bugs that are still open (that implies unaddressed in the candidate compose, updates repository or previous releases updates repository). QA does not approve the release if there are any open or otherwise unaddressed accepted blocker bugs or if validation testing is incomplete. There is no room for discretion in this determination. The Go/No-Go Meeting may serve as a blocker review meeting, if there are outstanding proposed blockers - as long as the necessary groups are present - in order to make the determination possible by deciding if they are accepted or rejected.


Release Criteria are set for each public release and are found at the following links:
Release Criteria are set for each public release and are found at the following links:
Line 17: Line 17:


== Meeting Outcomes ==
== Meeting Outcomes ==
# Decision as to whether the release is ''GOLD''.
# Decision as to whether the release is ''GO''.
#* If the release criteria are met the release is declared ''GOLD''.
#* If the release criteria are met the release is declared ''GO''.
#* If the release criteria are '''not''' met, the release is delayed by one week.  
#* If the release criteria are '''not''' met, the release is delayed by one week.  
# Release is unanimously declared ''GOLD'' by a representative from Development, Release Engineering, and Quality Assurance.
# Release is unanimously declared ''GO'' by a representative from Development, Release Engineering, and Quality Assurance.
# Once a release has been declared ''GOLD'' (release criteria satisfactorily met) its status cannot be changed.
# Once a release has been declared ''GO'' (release criteria satisfactorily met) its status cannot be changed.
#* No subsequently unfavorable test results will reverse this decision.
#* No subsequently unfavorable test results will reverse this decision.
# Email is sent to the following email lists announcing that the release has been declared ''GOLD'' by the meeting organizer.
# Email is sent to the following email lists announcing that the release has been declared ''GO'' by the meeting organizer.
#* [https://admin.fedoraproject.org/mailman/listinfo/logistics logistics@lists.fedoraproject.org]
#* [https://admin.fedoraproject.org/mailman/listinfo/logistics logistics@lists.fedoraproject.org]
#* [https://admin.fedoraproject.org/mailman/listinfo/devel-announce devel-announce@lists.fedoraproject.org]
#* [https://admin.fedoraproject.org/mailman/listinfo/devel-announce devel-announce@lists.fedoraproject.org]
Line 30: Line 30:


== Contingency Plan ==
== Contingency Plan ==
If the release criteria are not met the release cannot be declared ''GOLD'', the complete release slips by one week.
If the release criteria are not met the release cannot be declared ''GO'', the complete release slips by one week.

Revision as of 16:46, 26 February 2016

Before each public release Development, QA, and Release Engineering meet to determine if the release criteria are met for a particular release. This meeting is called the: Go/No-Go Meeting.

Verifying that the Release criteria are met is the responsibility of the QA Team. QA team's determination must be based on the blocker bug process. QA approves the release if all validation tests appropriate to the release phase (Alpha, Beta or Final) have been performed and there are no accepted blocker bugs that are still open (that implies unaddressed in the candidate compose, updates repository or previous releases updates repository). QA does not approve the release if there are any open or otherwise unaddressed accepted blocker bugs or if validation testing is incomplete. There is no room for discretion in this determination. The Go/No-Go Meeting may serve as a blocker review meeting, if there are outstanding proposed blockers - as long as the necessary groups are present - in order to make the determination possible by deciding if they are accepted or rejected.

Release Criteria are set for each public release and are found at the following links:

Meeting Organization

  1. The meeting facilitator sends an email announcement three days before the meeting, specifiying the meeting location and time:
  2. At the start of the meeting representatives from Development, Release Engineering, and Quality Assurance should be clearly identified

Meeting Outcomes

  1. Decision as to whether the release is GO.
    • If the release criteria are met the release is declared GO.
    • If the release criteria are not met, the release is delayed by one week.
  2. Release is unanimously declared GO by a representative from Development, Release Engineering, and Quality Assurance.
  3. Once a release has been declared GO (release criteria satisfactorily met) its status cannot be changed.
    • No subsequently unfavorable test results will reverse this decision.
  4. Email is sent to the following email lists announcing that the release has been declared GO by the meeting organizer.
  5. Staging to Fedora mirrors begins and cannot be reversed even if additional bugs are found.

Contingency Plan

If the release criteria are not met the release cannot be declared GO, the complete release slips by one week.