Testing Guide for 4.7-RELEASE
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.