On Thu, 2010-01-07 at 14:15 -0500, Will Woods wrote:
On Thu, 2010-01-07 at 12:01 -0500, Kamil Paral wrote:
> Hi,
>
> it seems to me that the kparal/rpmguard-integration branch is now
> mature enough to be merged into master.
>
> You can try the rpmguard test by issuing:
>
> 1. checkout kparal/rpmguard-integration branch
> 2. $ /usr/share/autoqa/post-koji-build/watch-koji-builds.py --dry-run
> 3. pick a line
> 4. $ (copy that line) -t rpmguard --local
>
> And look to stdout or rpmguard.log. Example rpmguard.log:
>
http://pastebin.com/f534d362f
>
http://pastebin.com/f42ca41cd
>
> What do you think, any objections to merge? Send all blame to me,
> thanks.
Everything looks good to me. Awesome work. I'll pull this into master
shortly.
> PS: It doesn't currently send results by email, same as current rpmlint
> test. I hope we will discuss enabling them both soon after.
Yeah, to do that we're going to need a library function to look up the
owner(s) of a given package from the pkgdb. Shouldn't be too hard,
though.
What's really interesting (but will be much trickier): I'm pretty sure
we're going to want to be able to hold/block/untag packages with certain
failures. That will require a whole big policy discussion with the
packaging committee and rel-eng, and some way of letting maintainers
sign off on expected failures..
We'll get there eventually. But probably we should start thinking about
exactly which problems should cause a package to be rejected, or held
for review. Does anyone know of an existing list/policy to use for a
starting point?
I'm not aware of anything so far. Kamil's work on rpmguard has sparked
a lot of excitement for me on the testing possibilities with package
updates. I don't know if it's too early to head down this path, but do
folks think the time is right to start working towards a [[QA:Package
Update Test Plan]] to outline the details and move the discussion
forward?
Thanks,
James