User:Adamwill/Draft workstation release criteria

Alpha

Post-install requirements

Except where otherwise specified, each of these requirements applies to all supported configurations described above.

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

• 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:
  • QA:Testcase_Anaconda_user_creation
  • QA:Testcase_base_initial_setup
  • QA:Testcase_base_startup

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

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

References

• 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

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

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

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

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

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

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

References

• Proposed 2010-06-24, implemented 2010-06-29
• Test case: QA:Testcase_desktop_updates

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.

References

• Proposed 2010-06-24, implemented 2010-06-29
• Test case: QA:Testcase_desktop_login

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

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

Exclusions

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

References

• 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

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

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

References

• 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

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

• Proposed 2010-09-10, implemented 2010-09-13
• Simplified as part of Fedora.next Product criteria revision
• Test case: QA:Testcase_base_startup