Alpha
Expected installed system boot behavior
- A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system.
- The system must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility.
In all of the above cases, if any system partitions were encrypted as part of the installation, the boot process must prompt for the passphrase(s) and correctly unlock the partition(s) when provided with the correct passphrase(s).
In all of the above cases, the boot should proceed without any unexpected user intervention being required. On a graphical install, if the user explicitly intervenes to prevent graphical boot by passing a bootloader parameter, the non-graphical requirement comes into effect.
System-specific bugs don't necessarily constitute an infringement of this criterion - for instance, if the system fails to boot because of a bug in the support some specific system's hardware, that is unlikely to constitute a violation unless the system is an extremely popular one. See Blocker_Bug_FAQ for more discussion of this.
These criteria can be used to cover known severe issues in applying post-release updates. For instance, if there was a bug that meant the system would install and boot fine but would break as soon as the user ran 'yum update', that may well be covered by these criteria.
On the first boot after installation, a utility for creating user accounts and other configuration may (may, not must) run prior to a log in screen appearing.
- Requirement for graphical installs to boot to desktop was in original Fedora 13 criteria revision.
- Changes to cover non-graphical installs were proposed 2010-08-12, implemented 2010-08-16.
- Changes to cover firstboot were proposed 2011-03-17, implemented 2011-03-29.
- Change to stop requiring text mode firstboot to work was proposed 2011-08-08, implemented 2011-08-17.
- Wording was simplified and clarified as part of the major Fedora 19 criteria revision.
- Change to reflect F19 firstboot->initial-setup/gnome-initial-setup migration and anaconda user creation proposed 2013-07-18, implemented 2013-07-24.
- Separated into per-Product variations as part of the Fedora.next Product split between Fedora 20 and Fedora 21, with only parts relevant to each Product included in each Product's criteria.
- Test cases:
Required applications
It must be possible to run the default web browser and a terminal application.
The web browser must be able to download files, load extensions (if applicable), and log into FAS.
- Requirement was in force for 'default desktop' in original Fedora 13 criteria revision.
- Modification to cover 'release-blocking desktops' was proposed 2011-05-17, implemented 2011-05-31.
- As part of Fedora.next product split revisions, Workstation-specific simplified variant created.
- Test cases: QA:Testcase_desktop_browser, QA:Testcase_desktop_terminal
Desktop background
The default desktop background must be different from that of the two previous stable releases.
- Initial artwork criteria proposed 2010-10-10, implemented 2010-10-13.
- Revision to be less strict and pervasive proposed 2012-08-28, implemented 2012-09-04.
- Copied unmodified to Workstation criteria as part of Fedora.next Product-based criteria split.
- Test case: QA:Testcase_base_startup
Beta
Working sound
The installed system must be able to play back sound with gstreamer-based applications.
System-specific bugs don't usually constitute an infringement of this criterion. It is meant to cover bugs which completely prevent sound playback from working in any hardware configuration. See Blocker_Bug_FAQ for more discussion of this.
- Part of original Fedora 13 criteria revision
- Test case: QA:Testcase_audio_basic
Desktop panel
No core desktop component may crash on startup or be entirely non-functional.
As long as the Workstation's desktop is GNOME 3, the major sub-components of the Shell itself are the "core desktop components". This criterion would apply to, for example, an expected element of the top panel being missing, or the overview, Dash, or window selector being broken.
- Part of original Fedora 13 criteria revision
- Simplified and modernized as part of Fedora.next Product-based criteria revisions
- Test case: QA:Testcase_desktop_panel_basic
Automatic mounting
Automatic mounting of removable media on insertion must work.
This criterion applies to optical discs, USB storage devices and hotpluggable eSATA hard disks, and any other similar devices that are considered by the developers to be supported.
- Part of original Fedora 13 criteria revision (later broadened from 'default desktop' to 'release-blocking desktops')
- Test case: QA:Testcase_desktop_automount
Updates
The installed system must be able to download and install updates with the default graphical package manager.
A bug in some particular update package will not usually constitute a violation of this criterion. It's really about the update mechanism functioning correctly. So if the package manager is working fine, but the update transaction fails because there happen to be two conflicting packages in the repositories, that's not a release blocking problem.
- Requirement was in force in Alpha for 'default desktop' in original Fedora 13 criteria revision.
- Modification to cover 'release-blocking desktops' was proposed 2011-05-17, implemented 2011-05-31.
- Modification to move graphical update requirement to Beta or Final agreed during 2013-09-18 blocker review meeting.
- Test case: QA:Testcase_desktop_updates
Update notification
The system must notify the user of available updates, but must not do so when running as a live image.
Desktop shutdown, reboot, logout
The desktop's offered mechanisms for shutting down, logging out and rebooting must work.
Similar to the Alpha criterion for shutting down, shutdown and reboot mechanisms must take storage volumes down cleanly and correctly request a shutdown or reboot from the system firmware. Logging out must return the user to the environment from which they logged in, working as expected.
Required core applications
The core applications listed in the Workstation technical specification must all be present on the media and a default installed system.
- Part of initial set of additional proposed Workstation criteria, 2014-07-04
- Test case: QA:Testcase_workstation_core_applications
Final
Critical path translations
All critical path actions must correctly display all sufficiently complete translations available for use.
This criterion covers bugs that cause available translations not to be shown. It does not require that any translations at all be available: 'something is not translated to my language' cannot constitute a violation of this criterion. The "sufficiently complete" wording refers to a mechanism in Fedora which means that translations are not actually included until they reach a certain percentage of completion.
- Proposed 2011-10-12, implemented 2011-10-14
- Test case: missing
SELinux and crash notifications
There must be no SELinux denial notifications or crash notifications on boot of the Product media, during installation, or at first login after a default install.
Notifications that only happen on unusual configurations are excluded: see Blocker_Bug_FAQ.
- Part of initial Fedora 13 criteria revision
- Slightly revised for major Fedora 19 criteria revision
- Simplified as part of Fedora.next Product criteria revision
- Test case: QA:Testcase_desktop_error_checks
Default application functionality
All applications that can be launched from the Overview after a default installation must start successfully and withstand a basic functionality test.
Basic functionality means that the app must at least be broadly capable of its most basic expected operations, and that it must not crash without user intervention or with only basic user intervention.
- Part of the 'menu sanity' block of the initial Fedora 13 criteria revision
- Revised to reduce scope as part of major Fedora 19 criteria revision
- Simplified as part of Fedora.next Product criteria revision
- Test case: QA:Testcase_desktop_menus
Default panel functionality
All elements of the desktop shell must function correctly in typical use.
This covers quite a wide range of features, including some pretty advanced stuff - you could argue that all elements of GNOME network configuration are covered because there's a network icon on the top panel, for instance. The intent of the criterion is more that very prominent features of the desktop don't break easily, so there's a subjective cut-off in there which is decided in the blocker review process. The key question is "would this bug cause significant inconvenience or just a really bad first impression to a typical user or reviewer of the release?"
- Part of the 'menu sanity' block of the initial Fedora 13 criteria revision
- Simplified as part of Fedora.next Product criteria revision
- Test case: QA:Testcase_desktop_panel_advanced
Desktop keyring
Saving passwords to and retrieving passwords from the default keyring must work.
- Part of the 'menu sanity' block of the initial Fedora 13 criteria revision
- Simplified as part of Fedora.next Product criteria revision
- Test case: QA:Testcase_desktop_keyring
Printing
It must be possible to successfully print a typical document or picture on a supported printer connected via USB.
A "supported" printer is one for which a working driver is included in Fedora: this criterion is intended to ensure the printer configuration and printing mechanisms broadly work, not to require every printer under the sun to work.
- Part of initial set of additional proposed Workstation criteria, 2014-07-04
- Test case: QA:Testcase_desktop_printing_local
Artwork
The proposed final Fedora artwork must be included and used as the background. All Fedora artwork visible in critical path actions must be consistent with the proposed final theme.
- Proposed 2010-09-10, implemented 2010-09-13
- Simplified as part of Fedora.next Product criteria revision
- Test case: QA:Testcase_base_startup
Theming
Applications using any of the GUI toolkits listed in the technical specification must all use the same theme, and that theme must be consistent in appearance across toolkits.
- Part of initial set of additional proposed Workstation criteria, 2014-07-04
- Test case: QA:Testcase_workstation_theming