add examples for micro and major versions
|Deletions are marked like this.||Additions are marked like this.|
|Line 1:||Line 1:|
|This document describes the policy for major updates to Clamav packages in a stable supported distro, including LTS. Micro-release updates are already covered under StableReleaseUpdates/MicroReleaseExceptions. Major updates require a different process because they generally involve interface changes in libclamav and require multiple packages to be tested and updated together to maintain functionality.||This document describes the policy for major updates to Clamav packages in a stable supported distro, including LTS. Micro-release updates (eg 0.94.1 to 0.94.2) are already covered under StableReleaseUpdates/MicroReleaseExceptions. Major updates (eg 0.94.2 to 0.95) require a different process because they generally involve interface changes in libclamav and require multiple packages to be tested and updated together to maintain functionality.|
This document describes the policy for major updates to Clamav packages in a stable supported distro, including LTS. Micro-release updates (eg 0.94.1 to 0.94.2) are already covered under StableReleaseUpdates/MicroReleaseExceptions. Major updates (eg 0.94.2 to 0.95) require a different process because they generally involve interface changes in libclamav and require multiple packages to be tested and updated together to maintain functionality.
Clamav is the premier FOSS anti-virus scanning engine. By its nature, the performance requirements for clamav evolve rapidly as new threats are discovered, so unlike normal packages, stabilizing the version and not changing it does not provide performance stability, it causes performance degradation. Updates to anti-virus signatures are downloaded regularly using freshclam, but often older scanning engines cannot use the signatures and detect newer threats. In order to provide continuing, first class performance and pace the threat, newer versions need to be integrated into existing Ubuntu releases.
QA of the update has three major components:
1. Qualification and test of the clamav package.
2. Qualification and test of the integration of the new clamav with its reverse dependencies.
3. Qualification and test of the installability and functionality of clamav and its reverse dependencies on the target release
Packages brought into an existing release must be brought in with a minimal difference from the development/current release (the process should branch from the earliest release to carry the current upstream release which may be the current release and may be the development release). They will go through some functional and integration testing first in the ubuntu-clamav PPA, then exposed to a broader audience in the *-backports repositories, and then finally delivered as updates to all users of each particular release.
Clamav package QA:
The clamav package itself includes a test suite that is enabled by default and make check is integrated into debian/rules, so if the package builds, it has passed its test suite (Dapper is an exception to this as the version of check in Dapper is too old). Some tests are skipped due to build-depends not being included (such as electric-fence). The tests that are reliable are included and activated. Tests that are not activated by default have been found to only find faults in the underlying system and not in the clamav package itself (valgrind and electric-fence).
Once the package is built, then it should be tested with the Security Team's QA regression test for clamav (see scripts/README for details on how to test).
These two steps should ensure the package is functional.
Integration and testing with the reverse dependencies and the target release are done together. The process for this is described in MOTU/Clamav/.
This process deviates in a few important respects from standard Ubuntu process and should be approved by the Ubuntu Tech Board.
- Generally library packages are not approved for backporting. In order to make it reasonable to make an exception to this rule, all packages that use libclamav are tested and backported in tandem (if needed) .
- Generally major version updates are not permitted post-release. Because anti-virus capability degrades over time due to new threats, in the case of clamav not updating only provides an illusion of stability. Updates are essential to maintain an even level of capability.
- Because the libclamav design is rapidly changing, its rdepends need active maintenance to remain functional. If an upstream is inactive, it may be necessary to drop support for a package in a post-release update. This is unfortunate, but may be unavoidable. In these cases, the dropped package should be used as a transitional package that depends on the most generally suitable alternative so users are not left without an installed, functional package.
This process has been experimentally executed from beginning to end twice. Dapper, Feisty, and Gutsy were updated to Clamav 0.92.2 (which is what Hardy was released with) and Dapper and Hardy were updated to 0.94.2 (which is what Intrepid was released with). So far, although labor intensive and taking longer to complete than would be ideal, this process has produced good results. When Dapper, Feisty, and Gutsy were updated only two bugs were filed (both Dapper). In one case a user needed to manually adjust a configuration file. In the other case the user had depended on a function provided by python-clamav that had been dropped in the newer release for his own private scanning tool. We were able to quickly package python-pyclamd and provide a suitable alternative. For the Dapper/Hardy update to 0.94.2, the only issue known so far was one rdepend misbuilt against the old clamav and that was quickly corrected.
This process have provided a good balance between cutting edge and stable, integrated capability and seems suitable to extend to Intrepid and Jaunty where clamav is in Main.