Legacy/QAPublish
From FedoraProject
Contents |
Testing packages for release to updates-testing (PUBLISH)
1. Download the SRPM package from the location specified in Bugzilla.
2. Inspect the code and .spec file looking for any problems. See the QA Checklist below for things to check.
- Also download the original SRPM or other relevant SRPMs and compare it against against evaluated package using tools such as rpm-build-compare.sh (available e.g., on the mailing list archives).
3. Verify that the patch comes from a trusted source (e.g., by doing a diff), should fix the bugs on the package.
- If the origin of the patch cannot be verified, the patch has to be carefully reviewed. Note any discrepancies.
If the changes have been non-trivial, you should also consider doing the following:
- Rebuild the SRPM and note any rebuild problems.
- Install the package, and note any installation problems.
- Use the package (as appropriate for the package), and note any problems found.
- Report your findings the a Bugzilla entry as described in QA Testing (for help on using Bugzilla, see LegacyBugzilla).
Recommendations for Publish QA
Publish QA can be done even if you do not have access to the OS version in question, because all you are required to do (when the changes are simple enough) is verify the correctness. Therefore when doing PUBLISH voting, it is good idea to check all the OS versions available at the same time, because the packages will not be rebuilt for updates-testing until all the OS versions have been voted for PUBLISH.
There are a couple of cases where you can give a PUBLISH and the problem can be corrected later
- RPM Versioning is not good; this can be fixed at build stage
- Buildrequires are missing; ditto.
- Changelog includes typos or needs beefing up; see above.
An example procedure for PUBLISH QA for simple updates
Using this process, there is experience of being able to do PUBLISH QA for 4 OS versions of a package in less than 15 minutes from the start to finish.
- Check the buglist.html and note the need for PUBLISH QA.
- Fetch all the proposed .src.rpm's for all the OS versions.
- Find out all the previous versions for those .src.rpm's, using 'list-latest.sh'
script (see QA Testing ). If there is a QA'd update or update-testing package, fetch those; if not (list-latest.sh doesn't show these), get the originals from Red Hat/Fedora repository.
- Run 'rpm-build-compare.sh' between the latest QA'd update and the proposed update,
for all the .src.rpm's.
- Go through the -diff.txt files generated using rpm-build-compare.sh; tips for efficiency below
1. Check which files have been added or deleted. Typically there should be no removals, just an added patch or two. You'll need to find out if something has been removed; note which ones have been added.
2. Check the SHA1sums for the included files. Ignore the new files (from above). Ignore the .spec file change which always happens. Take special note if there are others (typically there shouldn't be; if there are, these need to be checked carefully).
3. If all you had was an added patch (or two) and the .spec file changes, you can ignore the rest of the diffs and go straight into checking the .spec file (we'll look at the added patches later). Other change diffs need to be reviewed now.
4. Check that .spec file only includes the intended changes, e.g., bump of the release tag, added buildrequires, the added patch(es), applying the patch(es) with %patch, and the update of %changelog. In particular, verify that the patches have bee applied, the versioning is sane, and there are no other substantial changes.
- Now, you should have verified everything except the added patch files. Identify or guess the source of the patch. The good first try is Red Hat Enterprise Linux. Fetch appropriate package updates (e.g., RHEL21 or RHEL3), whichever versions match those being QA'd most closely (list-latest.sh shows these too).
- Run rpm-build-compare between the RHEL version(s) and a package being QA'd. This extracts the patch(es), and you can also check what other changes have been made in RHEL. Typically it's a good thing to identify whether they also fix other security problems which might have been overlooked here.
- find all the patches for all the OS versions, including the RHEL patch, using e.g., "find openssh* -name '*scp-attack*' -ls". First check the RHEL patch against one of the patches you're doing QA for (e.g., using "diff -b -B patch1 patch2"). If you're satisfied, check all the other patches with diff as well. Now you should have verified that patch(es) match those from a QA'd source.
- run something like "sha1sum openssh*legacy*.rpm > msg" and edit out older versions if any. Add your verify "story" on top.
- Check that the SHA1sums of the files you were doing QA for match those that the package proposer published in bugzilla.
- Sign the message (gpg --clearsign msg) and cut'n'paste it to bugzilla.
- If you're capable of doing so, update the StatusWhiteboard (remove "publish-*" for all the versions you QA'd, and add "needsbuild").
If there were issues (e.g., a patch for one version was missing something) and you cannot give PUBLISH vote right away, describe the issues clearly; the message does not need to be gpg signed.
QA Checklist for PUBLISH
The following is a QA checklist for the first step in the QA process. This is simply a checklist that should be done for each package during the first step of the QA process, but it is not the entire QA process. Each package may have steps unique to that package which are not listed here. If there are major changes in the spec file, fedora.us QAChecklist [1] may optionally be consulted.
Required checklist
1. Are the sources, patches, etc. correct and free from trojans?
- Check that source files are the same as previous releases (or the same as provided upstream in the case of a version upgrade). This involves downloading the previous release of the package and checking the sha1sum of the source against the new proposed source.
- Check the patches against upstream or RHEL patches. If you're not sure where the patches came from, ask the packager.
2. Does the package naming scheme follow the Fedora Legacy RPM Versioning conventions?
3. Check the spec file for any changes from the previous release. Most Legacy releases shouldn't change more than adding a patch (or multiple patches) and a changelog entry, as well as bumping the release number.
