On Thu, Aug 16, 2012 at 09:32:20PM -0400, Robert Middleswarth wrote: > Part of the process now include creating rpm packages. > http://jenkins.ovirt.info/view/patches/job/patch_engine_create_rpms/ > This allows people to download and test packages based on the change > if they want to. I wonder if this is needed by people. For me it duplicates the number of emails per change... BTW, I see that a failed job http://jenkins.ovirt.info/job/patch_vdsm_unit_tests/486/console does not set V-1 on the change. Could this be fixed? I'd like the poster and human reviewer to be perfectly aware that a change breaks unit tests. Regrads, Dan.

On Sun, Aug 19, 2012 at 04:06:09AM -0400, Robert Middleswarth wrote: > On 08/19/2012 03:21 AM, Dan Kenigsberg wrote: >> On Thu, Aug 16, 2012 at 09:32:20PM -0400, Robert Middleswarth wrote: >>> Part of the process now include creating rpm packages. >>> http://jenkins.ovirt.info/view/patches/job/patch_engine_create_rpms/ >>> This allows people to download and test packages based on the change >>> if they want to. >> I wonder if this is needed by people. For me it duplicates the number of >> emails per change... >> >> BTW, I see that a failed job http://jenkins.ovirt.info/job/patch_vdsm_unit_tests/486/console >> does not set V-1 on the change. Could this be fixed? I'd like the poster >> and human reviewer to be perfectly aware that a change breaks unit >> tests. >> >> Regrads, >> Dan. > This was detailed in an earlier email. I'm sorry that I've missed it. > There are limits related to > the current plugin and how it processes patches. The issue is > simple and effects job when aborted because someone isn't in the > whitelist. I have spent a lot of time testing diff options and the > best I could come up with is that we abort the process. The biggest > problem is the gerrit-trigger plugin treats aborts as if they are a > failure instead of as a non event. I tried several diff ways to > make it a non event but couldn't find one. The choice I went with > was to add text that they failed and leave them at zero the other > options was to mark all failure / aborts (Including people not in > the whitelist) as a -1 that wasn't really acceptable. There are 2 > diff bug reports and if either gets fixed we will be able to -1 > failures but until the are done I am very limited on the options. We'll make with what we've got. Thanks. Oh, and a tiny "security" comment: we may trust infallible(a)engineer.org but not her fallible(a)engineer.org colleague. So grep'ing the whitelist should be done with something like grep -q ^${email}$