Architectures/ARM/Quality Assurance

This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.

Introduction

There are currently no tests performed on software compiled for ARM, this page outlines the existing Fedora testing system - AutoQA, and will discuss plans for ARM integration.

AutoQA

AutoQA is the automated test system used in Fedora. Watchers (scheduled through cron ) look for Events ( eg - new package built in Koji, new repo has finished, creation of new installable images, updates in bodhi ). Once an event occurs it triggers automated tests.

Current Events monitored

• git-post-receive - tests run after action performed in git.
• post-bodhi-update - update in Bodhi requests to be moved in 'testing' or 'stable'.
• post-bodhi-update-batch
• post-koji-build - new package built in Koji.
• post-koji-build-batch
• post-repo-update - change in repository package contents or metadata.
• post-tree-compose - new tree compose ( installation/boot images, package repository and metadata )

Current Tests

• conflicts - checks for package conflicts. Runs potential_conflict from yum-utils. ( triggered by - post-repo-update )
• depcheck - checks to see if package would cause broken dependencies if pushed to live repositories. ( triggered by - post-bodhi-update event )
• rats_install - installation of guest machine(virt-install) using latest compose. ( triggered by - post-tree-compose)
• rats_sanity - Repository sanity check - tests check repodata, comps.xml validity, core package dependency closure and existence. ( triggered by - post-repo-update )
• repoclosure - ensures packages in a repository have all dependencies satisfied. ( triggered by - post-repo-update )
• rpmguard - compares difference between new and previous package versions, logging important changes only. ( triggered by - post-koji-build)
• rpmlint - checks for common package issues ( triggered by - post-koji-build )
• upgradepath - checks for package version problems in repositories. ( triggered by - post-bodhi-update-batch )

ARM specific tests

Some tests will need to be written specifically for ARM including:

• Kernel validation
• Image validation
• Individual package tests
• Creation of device specific hardware tests
  • test - networking, audio, graphics, usb storage, SD/MMC, serial connection.

Hardware Access & Repair

Currently not everyone working within Fedora has access to an ARM device so it will be necessary to provide access to developers to test their software. Once their testing is completed, the device needs to be restored to a pristine state. At this time Anaconda is not fully functional, so some possible solutions include:

• SD card switch - allows access to be transferred remotely from card reader to ARM device, allowing for remote machine repair (restoration).
• QEMU

Related Pages

• Alpha Release Criteria
• Beta Release Criteria
• Final Release Criteria