QA's Package update policy proposal

[Paul Howarth]

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.