From Fedora Project Wiki

Revision as of 22:43, 4 July 2014 by Adamwill (talk | contribs) (add test case references for new criteria to the new test cases what i just wrote)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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.
Encrypted partitions

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).

User intervention

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

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.

References

Required applications

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.

References

Desktop background

The default desktop background must be different from that of the two previous stable releases.

References

Beta

Working sound

The installed system must be able to play back sound with gstreamer-based applications.

System-specific bugs

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.

References

Desktop panel

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.

References

Automatic mounting

Automatic mounting of removable media on insertion must work.

Removable media

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.

References
  • 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.

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.

References

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.

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.

References

Final

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.

References

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.

Exclusions

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

References

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

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.

References
  • 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.

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?"

References

Desktop keyring

Saving passwords to and retrieving passwords from the default keyring must work.

References

Printing

It must be possible to successfully print a typical document or picture on a supported printer connected via USB.

Supported?

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.

References

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.

References

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.

References