From Fedora Project Wiki

Revision as of 18:48, 22 April 2014 by Roshi (talk | contribs) (Roshi moved page User:Roshi/QA/Cloud Final Release Criteria to User:Roshi/QA/Cloud Docs/Cloud Final Release Criteria: Reorganizing.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Final Objectives

The objective of the Final release is to:

  1. Provide a polished final release suitable for meeting the needs of our Target Audience

Final Release Requirements

In order to be released to the general public, a compose must meet all of the following criteria. This is intended to make the decision process as clear and straightforward as possible. Mostly met items are incomplete until they are met. Optional and nice to have items should not be included in this list.

There may be times where a requirement is unmet only in a particular configuration, such as with some keyboard layouts but not others, or if a particular character is used in a username, password or passphrase. In such cases, the release team should use their judgement and refer to precedent to determine whether or not the issue should be considered to block the release. They should consider the number of users likely to be affected by the issue, the severity of the case when the issue is encountered, and the ease or otherwise with which the issue can be avoided by both informed and uninformed users.

The term release-blocking desktops means all the desktop environments in which bugs are currently considered capable of blocking a Fedora release. The current set of release-blocking desktops for x86_64 is GNOME and KDE, and for aarch64 is GNOME. Note that bugs in desktops that are not part of this set which would infringe these criteria automatically qualify for freeze exception status, according to the freeze exception bug process.

The term release-blocking images means all the images in which bugs are currently considered capable of blocking a Fedora release. The current set of release-blocking images includes the images defined by the three Editions - Server, Workstation and IoT - in their product requirement documents and/or technical specifications, the Everything network install image, key Cloud images, and the KDE live image. The canonical list of release-blocking images for Fedora 41 is on this page.

Process requirements

Beta criteria met

All Fedora 20 Beta Release Criteria must be met.

Final blockers CLOSED

All bugs blocking the Final tracker must be CLOSED.

Media consistency verification

Validation of install media must work correctly for all release-blocking images.

Details

This means that the installer's mechanism for verifying that the install medium is intact must complete successfully if the medium is correctly written and return a legible failure message if it is not.

References

Virtualization requirements

Xen DomU

The release must boot successfully as Xen DomU with releases providing a functional, supported Xen Dom0 and widely used cloud providers utilizing Xen.

Dom0 not covered

This criterion specifically does not cover Dom0 functionality: we only absolutely require that DomU functionality must work.

References

Post-install requirements

System services

All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present.

References
  • Part of initial Fedora 13 criteria revision
  • Rewritten more specifically for major Fedora 19 criteria revision
  • Test case: QA:Testcase_Services_start

SELinux and crash notifications

There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop.

Exclusions

Notifications that only happen on unusual configurations are excluded: see Blocker_Bug_FAQ.

References

Data corruption

All known bugs that can cause corruption of user data must be fixed or documented at Common F20 bugs.

User data?

"User data" really means data: attempts have been made to apply this criterion to things like trivial items of configuration being reset on upgrades or the setting of the system clock, but that is not going to fly.

Fixed or documented?

If the issue is sufficiently serious, we may consider that documenting it is not sufficient and it must be fixed. This is a subjective determination that will be made at blocker review or Go/No-Go meetings.

References
  • Part of initial Fedora 13 criteria revision
  • Test case: N/A (a test case for this criterion is not practical, it instead covers all "known bugs")

Security bugs

The release must contain no known security bugs of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation).

Determination

Determination of the classification of a bug can be done by those present at a blocker review or Go/No-Go meeting if necessary, but if the Fedora or Red Hat security team provides a classification, we will usually defer to their wisdom.

References

Release notes

The final branded release notes must be present on release-blocking images and the appropriately versioned generic release notes must be available in the release repository.

References

Release identification

A fedora-release package containing the correct names, information and repository configuration for a final Fedora release must be present on release-blocking images and the appropriately versioned generic-release package must be available in the release repository.

References

Final Blocker Bugs

A bug is considered a Final blocker bug if any of the following criteria are met:

A Fedora Change being incomplete, in and of itself, does not constitute a blocker bug. The Change process is separate from this process. Changes are required to meet certain standards at certain points of the release cycle, but this is part of the Change process and managed, tracked and enforced separately from this process. However, if a proposed feature being incomplete causes any of the above criteria to be met, then the bug is a release blocker.


Contingency Plan

  • If all of the Final Release Requirements are not met by 20:00 UTC on Tuesday the week prior to release day, the release will be delayed by one week so that the Final Release Requirements can be met.
  • One week will be added to all remaining tasks in the release schedule, including the final release date.
  • This decision will be made at the Go/No-Go Meeting.

Confirming Final Requirements

QA has the responsibility of determining whether the criteria for the release has been met (as outlined above) through discussion with Development and Release Engineering. QA's findings will be reviewed and discussed at the Go/No-Go Meeting.

Related Pages