---
title: "Testing Guide for 4.7-RELEASE"
sidenav: download
---
++++
Goals
As part of our on-going effort to improve the release engineering
process, we have identified several areas that need significant
quality assurance testing during the release candidate phase.
Below, we've listed the changes in 4.7-RELEASE that we feel merit
the most attention due to their involving substantial changes to the
system, or having arrived late in the development cycle leading up
to the release. In general, our goal in the QA process is to
attempt to check a number of things:
- The system has not regressed with respects to stability, correctness,
interoperability, or performance of features present in prior
releases.
- New features result in the desired improvement in stability,
correctness, interoperability, or performance.
To effectively determine this, it's desirable to test the system in
a diverse set of environments, applying a wide set of workloads,
forcing the system to operate both within and outside its normal
specification. Particular focus should often be placed on the
continuing (or new) capability of the system to perform correctly
when used in concert with systems from other vendors.
Features to explore carefully:
The release notes will always be
a good place to look for things to test.
Known Issues
- The 4.7-RC1 snapshots were built without packages due to some
problems (which only recently came to light) in the bzip2 package
support. Resolution: The RE team decided to return to
gzip packages for 4.7-RC2 (as well as any subsequent RC snapshots
and the final release), thus allowing this snapshot to have its
normal package set.
- Partially as a result of the above package problems, the ports
tree on the 4.7-RC1/i386 ISO image is not exactly the same as the
4.7-RC1/i386 FTP directory. Both will be eventually updated for
subsequent RC snapshots and the final release.
Resolution: Not a factor for subsequent snapshots.
- Loading kernel modules on 4.7-RC1/alpha is broken.
Resolution: A fix has
been committed and will be present in 4.7-RC2/alpha.
- When booting from the install media (e.g. a CDROM), sysinstall
tries to load a set of modules from the mfsroot image. For some
reason, sysinstall cannot load the module containing the aac
driver; this results in an error dialog when starting sysinstall.
Access to aac devices from within sysinstall is, understandably,
broken by this error. This appears to be due to a
dependency on the linux module. Resolution: The aac driver was
brought back into the install kernels, and other modules were
moved to modules.
++++