From Fedora Project Wiki
No edit summary
Line 5: Line 5:
* Where: #fedora-arm on Freednode
* Where: #fedora-arm on Freednode


Please join us 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 Fedora ARM users.
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 Fedora ARM users.
==Participants==
==Participants==
Please add your name, followed by your IRC nick:
Please add your name, followed by your IRC nick:
* Paul Whalen - pwhalen
* Paul Whalen - pwhalen
 
===Test Results===
=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 [[Template:Result | link ]] for examples on how to report test results. Then copy the wiki source of the below tests and results chart to a page you will create, using the hardware you are testing as the end of the url. For example if you are testing a Pandaboard with SD card, use a link similar to "Architectures/ARM/Quality Assurance/2012-06-15-VFAD-Fedora 17 Test Day-Pandaboard-SD" to record your results. Once completed add the link to overall results chart., and an assessment if the image is ready.
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 [[Template:Result | link ]] for examples on how to report test results.  
==Alpha Release Requirements==
 
# A correct checksum must be published for each official release image.
# 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
# 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.
# 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
# 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
# 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
# The installed system must be able to download and install  updates with yum and the default graphical package manager in all release-blocking desktops
# 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. 
# 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.
# 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===
{|class="wikimedia" style="t1" rowclass="th" width="100%"
{|class="wikimedia" style="t1" rowclass="th" width="100%"
! Hardware !! Who's Testing !! Alpha 1 !! Alpha 2 !! Alpha 3 !! Alpha 4 !! Alpha 5 !! Alpha 6 !! Alpha 7 !! Alpha 8 !! Alpha 9 !! Alpha 10
! Hardware !! Who's Testing !! Result !! Link to Results Page !! Final Notes
|-
|-
|| Versatile Express (Qemu) || ||{{result|pass|pwhalen}} || || || || || || || || ||
|| Versatile Express (Qemu) || || || ||
|-
|-
|| Versatile Express+XFCE (Qemu)  || || || || || || || || || || ||
|| Versatile Express+XFCE (Qemu)  || || || ||
|-
|-
|| Pandaboard || || || || || || || || || || ||
|| Pandaboard || || || ||
|-
|-
|| Pandaboard+XFCE || || || || || || || || || || ||
|| Pandaboard+XFCE || || || ||
|-
|-
|| Trimslice Bare/Value Pro/H/H250 || || || || || || || || || || ||
|| Trimslice Bare/Value Pro/H/H250 || || || ||
|-
|-
|| Trimslice Pro/H/H250 || || || || || || || || || || ||
|| Trimslice Pro/H/H250 || || || ||
|-
|-
|| Highbank || || || || || || || || || || ||
|| Highbank || || || ||
|-
|-
|| Beagleboard XM || || || || || || || || || || ||
|| Beagleboard XM || || || ||
|-
|-
|| Kirkwood (sheevaplug, dreamplug, guruplug, etc) || || || || || || || || || || ||
|| Kirkwood (sheevaplug, dreamplug, guruplug, etc) || || || ||
|-
|-|| || ||
|| Raspberry Pi+XFCE || || || || || || || || || || ||
|| Raspberry Pi+XFCE || || || ||
|-
|-
|| Raspberry Pi || || || || || || || || || || ||
|| Raspberry Pi || || || ||
|}
|}
====Alpha Test Notes====
Please add notes about your finding below:


==Beta Release Requirements==
==Tests==
# The images must not be over 4G in size, uncompressed.
 
# 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.
# Does your downloaded image have the correct checksum?
# 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.
# Does the system boot?
# 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.
# If graphical hardware is present, does the system successfully boot to the GUI?
# Automatic mounting on insertion of removable media must work in release-blocking desktops.
# If no graphical hardware is present, does the system successfully boot to a login prompt?
# The default update manager in release-blocking desktops must  periodically check for updates when  running on an installed system.
# 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, and log into FAS.
# All release-blocking desktops' offered mechanisms (if any) for shutting down, logging out and rebooting must work.
# Are you able to download and install updates with yum, and if available the default graphical package manager?
===Beta Test Results===
# If graphical is available, is the default Fedora artwork used?
# Is logging functional? It must provide at least basic local file-based logging of kernel messages, and allow other components to write log messages.
# Are you able to shutdown the system using standard console commands?
# Is the uncompressed image less then 4GB?
# If audio device support is present, does it work?
# On graphical hardware - Are the desktop's panels working and fully functional?
# On graphical hardware - Is media automatically detected when inserted?
# Does the update manager periodically check for updates?
# On graphical hardware - do offered mechanisms (if any) for shutting down, logging out and rebooting work?
# Do all default services start properly?
# All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use
#Menu sanity - only on hardware with graphical
##All Applications listed in the system menus (or equivalent) must have icons which have a consistent appearance and sufficiently high resolution to avoid appearing blurry
##Do all applications listed under the Applications menu or category start successfully?
##Do all applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a  few minutes of normal use. They must also have working Help and Help -> About menu items
##Ensure no application appears more then once twice in the menus. In particular, items under System must not appear under Applications
#Do all elements of the default panel (or equivalent) configuration in all release-blocking desktops function correctly in common use?
#Does Saving passwords in the desktop default keyring (if the desktop implements one), and retrieving passwords from the keyring work?
#Is the correct default Fedora wallpaper appear?
#Are the final branded release notes from the Documentation team present on the installed media and the appropriately versioned generic release notes must be available in the online release repository
===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
! Test !! Result !! Notes
|-
|-
|| Versatile Express (Qemu) || || || || || || || ||
|| 1 || ||
|-
|-
|| Versatile Express+XFCE (Qemu) || || || || || || || ||
|| 2 || ||  
|-
|-
|| Pandaboard || || || || || || || ||  
|| 3 || ||  
|-
|-
|| Pandaboard+XFCE || || || || || || || ||  
|| 4 || ||
|-
|-
|| Trimslice Bare/Value Pro/H/H250 || || || || || || || ||  
|| 5 || ||  
|-
|-
|| Trimslice Pro/H/H250 || || || || || || || ||  
|| 6 || ||  
|-
|-
|| Highbank || || || || || || || ||  
|| 7 || ||  
|-
|-
|| Beagleboard XM || || || || || || || ||  
|| 8 || ||  
|-
|-
|| Kirkwood (sheevaplug, dreamplug, guruplug, etc) || || || || || || || ||  
|| 9 || ||  
|-|| || ||
|| 10 || ||   
|-
|-
|| Raspberry Pi+XFCE || || || || || || || ||  
|| 11 || ||
|-
|-
|| Raspberry Pi || || || || || || || ||
|| 12 || ||
|}
====Beta Test Notes====
Please add notes about your finding below:
 
==Final Release Requirements==
# All services in a default install must start properly
# All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use
#Menu sanity - the following criteria refer to both a live  image and default installed system, and to all release-blocking desktops
##All Applications listed in the system menus (or equivalent) must have icons which have a consistent appearance and sufficiently high resolution to avoid appearing blurry
##All applications listed under the Applications menu or category  must start successfully
##All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a  few minutes of normal use.  They must also have  working Help and Help -> About menu items
##No application may unintentionally appear twice in the menus. In particular, items under System must not appear under  Applications
#All elements of the default panel (or equivalent)  configuration in all release-blocking desktops must function correctly  in common use
#Saving passwords in the desktop default keyring (if the  desktop implements one), and retrieving passwords from the keyring, must work for all release-blocking desktops
#The proposed final Fedora artwork must be included and enabled  by  default for the installer, graphical boot, firstboot, graphical login and desktop background.  All Fedora artwork must be consistent  with the proposed final theme, and if any artwork contains a graphical  version number, the version number used must match the Fedora release  number.  Generic release  artwork (e.g. Alpha, Beta, Development) must  not be used for the final release
#No notices or alerts about pre-release status should be present
#The final branded release notes from the Documentation team  must be present on ISO media and the appropriately versioned generic  release notes must be available in the online release repository
#A fedora-release  package containing the correct names, information and repository  configuration for a final Fedora  release (as opposed to a pre-release)  must be present on media while the appropriately versioned generic-release package must be available in the online release repository.
===Final Test Results===
{|class="wikimedia" style="t1" rowclass="th" width="100%"
! Hardware !! Who's Testing !! Final 1 !! Final 2 !! Final 3-1 !! Final 3-2 !! Final 3-3 !! Final 3-4 !! Final 4 !! Final 5 !! Final 6 !! Final 6 !! Final 7 !! Final 8 !! Final 9
|-
|-
|| Versatile Express (Qemu) || || || || || || || || || || || || || ||
|| 13 || ||
|-
|-
|| Versatile Express+XFCE (Qemu)  || || || || || || || || || || || || || ||
|| 14 || ||
|-
|-
|| Pandaboard || || || || || || || || || || || || || ||
|| 15 || ||
|-
|-
|| Pandaboard+XFCE || || || || || || || || || || || || || ||
|| 16 || ||
|-
|-
|| Trimslice Bare/Value Pro/H/H250 || || || || || || || || || || || || || ||
|| 17 || ||
|-
|-
|| Trimslice Pro/H/H250 || || || || || || || || || || || || || ||
|| 18 || ||
|-
|-
|| Highbank || || || || || || || || || || || || || ||
|| 19 || ||
|-
|-
|| Beagleboard XM || || || || || || || || || || || || || ||
|| 20 || ||
|-
|-
|| Kirkwood (sheevaplug, dreamplug, guruplug, etc) || || || || || || || || || || || || || ||
|| 21 || ||
|-|| || ||
|| Raspberry Pi+XFCE || || || || || || || || || || || || || ||
|-
|-
|| Raspberry Pi || || || || || || || || || || || || || ||
|| 22 || ||  
|}
|}
====Final Test Notes====
Please add notes about your finding below:

Revision as of 13:57, 15 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 Fedora ARM users.

Participants

Please add your name, followed by your IRC nick:

  • Paul Whalen - pwhalen

Test Results

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. Then copy the wiki source of the below tests and results chart to a page you will create, using the hardware you are testing as the end of the url. For example if you are testing a Pandaboard with SD card, use a link similar to "Architectures/ARM/Quality Assurance/2012-06-15-VFAD-Fedora 17 Test Day-Pandaboard-SD" to record your results. Once completed add the link to overall results chart., and an assessment if the image is ready.

Hardware Who's Testing Result Link to Results Page Final Notes
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

Tests

  1. Does your downloaded image have the correct checksum?
  2. Does the system boot?
  3. If graphical hardware is present, does the system successfully boot to the GUI?
  4. If no graphical hardware is present, does the system successfully boot to a login prompt?
  5. 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, and log into FAS.
  6. Are you able to download and install updates with yum, and if available the default graphical package manager?
  7. If graphical is available, is the default Fedora artwork used?
  8. Is logging functional? It must provide at least basic local file-based logging of kernel messages, and allow other components to write log messages.
  9. Are you able to shutdown the system using standard console commands?
  10. Is the uncompressed image less then 4GB?
  11. If audio device support is present, does it work?
  12. On graphical hardware - Are the desktop's panels working and fully functional?
  13. On graphical hardware - Is media automatically detected when inserted?
  14. Does the update manager periodically check for updates?
  15. On graphical hardware - do offered mechanisms (if any) for shutting down, logging out and rebooting work?
  16. Do all default services start properly?
  17. All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use
  18. Menu sanity - only on hardware with graphical
    1. All Applications listed in the system menus (or equivalent) must have icons which have a consistent appearance and sufficiently high resolution to avoid appearing blurry
    2. Do all applications listed under the Applications menu or category start successfully?
    3. Do all applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items
    4. Ensure no application appears more then once twice in the menus. In particular, items under System must not appear under Applications
  19. Do all elements of the default panel (or equivalent) configuration in all release-blocking desktops function correctly in common use?
  20. Does Saving passwords in the desktop default keyring (if the desktop implements one), and retrieving passwords from the keyring work?
  21. Is the correct default Fedora wallpaper appear?
  22. Are the final branded release notes from the Documentation team present on the installed media and the appropriately versioned generic release notes must be available in the online release repository

Results

Test Result Notes
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22