On 09/03/10 20:43, James Laska wrote:
Some basics I'd propose as a starting point for defining
acceptance
criteria include:
1. repoclosure/conflicts - no package update can introduce broken
deps or conflicts. I'd recommend we apply this to both
'updates-testing' and 'updates' (but that's detailed below)
2. Package sanity
* No rpmlint failures
rpmlint, in common with many other "lint" tools, reports things that it
thinks *may* be errors that actually are intended. To regard "no rpmlint
failures" as a package sanity check is way over the top I think.
Comparing the rpmlint output for an updated package with the rpmlint
output for the currently in-repo package would be more useful as that
could identify any new issues, but there should still be a means to
override rpmlint if the maintainer can explain why it's not a problem.
Paul.