How to do QA

[Charles R. Anderson]

On Fri, Feb 06, 2004 at 02:14:19AM +0100, Jonas Pasche wrote:
> http://jonaspasche.de/fedoralegacy/qa-howto.html

1. can be removed.
2. should be kept.

3. is tricky.  It shouldn't need to be checked unless we are fixing a 
Red Hat spec file problem.  If the update is purely for security 
patches/upstream source upgrade, then %pre/%post should rarely be 
affected by these types of changes.

4. I think this can be removed entirely, since in our domain all
packages are updates to Red Hat packages.

5. is important since our buildsystem requires that all BuildRequires:
be stated explicitly.

6. - 11. are unimportant for legacy updates.  They are pedantic spec
file policies that, while a very good idea for new packages, have
little relevance to our project goals.  Again, this depends on whether
the update is strictly fixing upstream sources, or the spec file
itself.  Patches to upstream sources should modify the spec file as
little as needed.

12. - 13. are good things to check, but changes to 13. should be
discussed with the community first.  Making a package run as a
different user (or in a chroot for example) is a major change to how a
package functions.  It may be necessary to do this to provide a
security update to a package, however.

14. doesn't really matter.

15. is very important IMO.  If these types of checks are not done,
then an update could be missing large parts of its functionality when
combined with undetected missing BuildRequires.  Since our buildsystem
doesn't install everything at build time (unlike Red Hat's) this is a
real concern for us.