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.
Kamil
PS: It doesn't currently send results by email, same as current rpmlint test. I hope we will discuss enabling them both soon after.
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:
- checkout kparal/rpmguard-integration branch
- $ /usr/share/autoqa/post-koji-build/watch-koji-builds.py --dry-run
- pick a line
- $ (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?
-w
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:
- checkout kparal/rpmguard-integration branch
- $ /usr/share/autoqa/post-koji-build/watch-koji-builds.py --dry-run
- pick a line
- $ (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
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:
- checkout kparal/rpmguard-integration branch
- $ /usr/share/autoqa/post-koji-build/watch-koji-builds.py --dry-run
- pick a line
- $ (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.
Actually, one question - did you make rpmguard AGPLv3 (instead of GPLv3) intentionally? If so, why? Should we think about relicensing other tests as AGPLv3?
-w
autoqa-devel@lists.fedorahosted.org