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.
Use for severe issues in applying updates
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.
First boot utilities
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:
It must be possible to run the default web browser and a terminal application.
Web browser requirements
The web browser must be able to download files, load extensions (if applicable), and log into FAS.
The default desktop background must be different from that of the two previous stable releases.
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.
No core desktop component may crash on startup or be entirely non-functional.
Core desktop component?
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.
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
The installed system must be able to download and install updates with the default graphical package manager.
Bugs in particular updates
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.
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.
Critical path translations
All critical path actions must correctly display all sufficiently complete translations available for use.
What does this cover, exactly?
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.
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.
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?"
Saving passwords to and retrieving passwords from the default keyring must work.
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.
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.
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.