Hi,
In order to streamline the Fedora Legacy process, I've the following suggestion for enhancing the role separation of QA testing:
1) The submitter of packages builds them, and tests whether the new packages work ("these packages should be OK, I've tested them")
XXX: does this place too much burden on the package submitter ?
2) The PUBLISH QA is only obligated to check that the modifications seem OK -- the sources have not been tampered with, the patches come from some reliable source or are otherwise OK, the spec file changes are minor, etc.
PUBLISH QA is also charged with identifying that the patches made actually fix the vulnerabilities that the update is trying to fix.
PUBLISH QA should be done for all the .src.rpm packages for all the distribution versions if possible.
* PUBLISH QA is *not* charged with rebuilding the package, installing the binary RPM, or testing it. It can do this of course. The main purpose is to just quickly make sure that the submitted packages _seem_ to be OK, and should be rebuildable in mach.
3) the VERIFY QA is obligated to:
- check the GPG signature and checksum of the packages
- install it, run it, test if it works.
- running rpm-build-compare.sh on the binaries to see if there have been any significant changes (e.g., to the libraries used)
* VERIFY QA optional tasks are:
- running rpm-build-compare.sh to the SRPM and/or other tasks related to PUBLISH QA.
Justification: currently PUBLISH QA is not being done especially for obscure packages that no one is really using, because it's difficult to rebuild and install and test them. We need to make this available to *anyone*, even to those who don't run the Red Hat version in question.
This makes updates-testing a bit more literally "testing", but IMHO that's not a problem.
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
-- fedora-legacy-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-legacy-list
