rpmguard -- what's next?

[James Laska]

Greetings folks,

Please don't take this post to mean, "drop what you are doing and let's
focus on rpmguard".  I believe our current focus is correctly centered
around automating the package update acceptance test plan [1].  Kamil
and I have discussed some long-term plans for rpmguard, but I also
wanted to bring the discussion to the list for group consumption/review.

Quick background, rpmguard does a fair amount of comparative tests
against old and new set of packages.  Heck, the tests are event
documented [2] (nicely done Kamil!).  Today, Seth Vidal directed me to
bug#564018 and asked whether rpmguard had support for testing whether a
package has a *large* change in it's %provides.  In the bug, the erlang
package went from 50 provides to 22157 provides.  This package did go
through rpmguard and warnings were generated (for a good laugh, see
[3]).  So kudos are in order for capturing the change in an automated
manner.

What interested me about this exercise was how a new test might be added
to rpmguard.  The power of rpmguard is in abstracting the details of
locating the previous packages and providing a common framework for
comparisons against the two package sets.  Presently, the tests exist in
the main driver.  

How do we want to extend this in the future make it easier/faster to
support new comparison tests?  Should tests exist in stand-alone python
scripts, where they all accept a common set of arguments?  It seems like
rpmlint is structured this way [4], is this good/bad ... does this make
user-contributed comparative tests easier?

Something Kamil proposed a while back, should rpmguard be a stand-alone
tool (much like rpmlint)?  Instead of being bundled inside autoqa,
anyone could do: `yum install rpmguard`

Apologies for the ranty nature of the email, I'm still thinking this
through.  My main objective is to get a sense where rpmguard should go.
Hopefully these thoughts can lead to a wiki or TRAC roadmap, and
something we could implement once our immediate objects are behind us.

Thanks,
James

[1]
https://fedoraproject.org/wiki/QA:Package_Update_Acceptance_Test_Plan
[2] https://fedorahosted.org/autoqa/wiki/RpmguardChecks
[3]
https://fedorahosted.org/pipermail/autoqa-results/2010-April/017795.html
[4] http://rpmlint.zarb.org/cgi-bin/trac.cgi/browser/trunk