From Fedora Project Wiki
Line 95: Line 95:
===Final Test Results===
===Final Test Results===
{|class="wikimedia" style="t1" rowclass="th" width="100%"
{|class="wikimedia" style="t1" rowclass="th" width="100%"
! Hardware !! Who's Testing !! Beta 1 !! Beta 2 !! Beta 3 !!Beta 4 !! Beta 5 !! Beta 6 !! Beta 7 !! Beta 8 !! Beta 9 !! Beta 10
! Hardware !! Who's Testing !! Final 1 !! Final 2 !! Final 3 !! Final 4 !! Final 5 !! Final 6 !! Final 7 !! Final 8 !! Final 9 !! Final 10
|-
|-
|| Versatile Express (Qemu) || || || || || || || || || || ||
|| Versatile Express (Qemu) || || || || || || || || || || ||

Revision as of 18:02, 14 June 2012

Fedora ARM VFAD - Final push to F17

  • When: Friday June 15th at 12PM EDT
  • Where: #fedora-arm on Freednode

Please join on Friday June 15th as we test all available images to be used in the Fedora 17 ARM RC1. All can participate - even if you lack hardware you can greatly assist us by testing the functionality of our QEMU images, as well as in updating our wiki where appropriate. Our aim is to remove outdated material, and add areas that include answers to frequently asked questions, installation and usage instructions for specific hardware and anything else that may help users.

Participants

Please add your name, followed by your IRC nick:

  • Paul Whalen - pwhalen

Tests to be performed

Please add your name to the wiki beside the hardware you will be testing as well as the media you will be using (eg SATA, SD). See this link for examples on how to report test results.

Alpha Release Requirements

  1. A correct checksum must be published for each official release image.
  2. There must be no file conflicts (cases where the files in some packages conflict but the packages have explicit Conflicts: tags are acceptable) or unresolved package dependencies in the released rootfs images
  3. Starting with the F18-ARM release: In most cases a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to the 'firstboot' utility on the first boot after installation (possibly after automated resizing or other steps, possibly also including a reboot), without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode the system is booted without an interactive user interface (e.g., headless). This includes correctly accessing any encrypted partitions when the correct passphrase is supplied. The firstboot utility must be able to create a working user account, set the root password, and set the timezone and current time.
  4. Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to a working graphical environment without unintended user intervention, if graphic hardware and user interface devices (pointer, keyboard) are available. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied
  5. When booting a system installed without a graphical environment, or when using a correct configuration setting to cause an installed system to boot in non-graphical mode, the system should boot to a state where it is possible to log in through at least one of the default virtual consoles
  6. It must be possible to run the default web browser and a terminal application from all release-blocking desktop environments. The web browser must be able to download files, load extensions, and log into FAS
  7. The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops
  8. The default Fedora artwork must either refer to the current Fedora release under development (Fedora 17), or reference an interim release milestone (e.g. Alpha or Beta). If a release version number is used, it must match the current Fedora release under development. This includes artwork used in the installer, graphical bootloader menu, firstboot, graphical boot, graphical login and desktop background.
  9. A system logging infrastructure must be available and enabled by default. It must provide at least basic local file-based logging of kernel messages, and allow other components to write log messages. This must be done in accordance with relevant standards accepted by the Project.
  10. It must be possible to trigger a system shutdown using standard console commands, and the system must shut down in such a way that storage volumes (e.g. simple partitions, LVs and PVs, RAID arrays) are taken offline safely.

Alpha Test Results

Hardware Who's Testing Alpha 1 Alpha 2 Alpha 3 Alpha 4 Alpha 5 Alpha 6 Alpha 7 Alpha 8 Alpha 9 Alpha 10
Versatile Express (Qemu)
Pass pass pwhalen
Versatile Express+XFCE (Qemu)
Pandaboard
Pandaboard+XFCE
Trimslice Bare/Value Pro/H/H250
Trimslice Pro/H/H250
Highbank
Beagleboard XM
Kirkwood (sheevaplug, dreamplug, guruplug, etc)
Raspberry Pi+XFCE
Raspberry Pi

Alpha Test Notes

Please add notes about your finding below:

Beta Release Requirements

  1. The images must not be over 4G in size, uncompressed.
  2. When booting a system installed without a graphical environment, or when using a correct configuration setting to cause an installed system to boot in non-graphical mode, the system should provide a working login prompt without any unintended user intervention when boot is complete, and all virtual consoles intended to provide a working login prompt should do so, except for a character-mode firstboot if provided.
  3. In most cases, the installed system must be able to play back sound with gstreamer-based applications (see Blocker_Bug_FAQ), if supported audio output devices are present.
  4. No part of any release-blocking desktop's panel (or equivalent) configuration should crash or be entirely non-functional on boot of the installed system using default installation choices.
  5. Automatic mounting on insertion of removable media must work in release-blocking desktops.
  6. The default update manager in release-blocking desktops must periodically check for updates when running on an installed system.
  7. All release-blocking desktops' offered mechanisms (if any) for shutting down, logging out and rebooting must work.

Beta Test Results

Hardware Who's Testing Beta 1 Beta 2 Beta 3 Beta 4 Beta 5 Beta 6 Beta 7 Beta 8 Beta 9 Beta 10
Versatile Express (Qemu)
Versatile Express+XFCE (Qemu)
Pandaboard
Pandaboard+XFCE
Trimslice Bare/Value Pro/H/H250
Trimslice Pro/H/H250
Highbank
Beagleboard XM
Kirkwood (sheevaplug, dreamplug, guruplug, etc)
Raspberry Pi+XFCE
Raspberry Pi

Beta Test Notes

Please add notes about your finding below:

Final Release Requirements

Final Test Results

Hardware Who's Testing Final 1 Final 2 Final 3 Final 4 Final 5 Final 6 Final 7 Final 8 Final 9 Final 10
Versatile Express (Qemu)
Versatile Express+XFCE (Qemu)
Pandaboard
Pandaboard+XFCE
Trimslice Bare/Value Pro/H/H250
Trimslice Pro/H/H250
Highbank
Beagleboard XM
Kirkwood (sheevaplug, dreamplug, guruplug, etc)
Raspberry Pi+XFCE
Raspberry Pi

Final Test Notes

Please add notes about your finding below: