Yes, I can do that.
17.11.2017 21:27 "Nir Soffer" <nsoffer@redhat.com> napisał(a):On Mon, Oct 16, 2017 at 8:36 AM Dan Kenigsberg <danken@redhat.com> wrote:On Mon, Oct 16, 2017 at 8:25 AM, Barak Korren <bkorren@redhat.com> wrote:
>
>
> On 15 October 2017 at 19:43, Dan Kenigsberg <danken@redhat.com> wrote:
>>
>>
>> Down sides are waste of resources, slower CI responsiveness, and more
>> importantly: rawhide fragility may cause more unrelated failures.
>
>
> I don't think it will be that much of a resource issue. Our non-peak slave
> utilization is pretty low. And you can just remove some of the older Fedora
> versions.
>
> I suggest not to make too many premature assumptions. If rawhide testing is
> useful for you, just add it and see how it behaves over time...
>
>> Nir, with your experience - does it worth it?
>>
>> How about having "rawhide" as non-voting?
>
>
> You can accomplish that easily - just add a 'check-patch.sh.fcraw' script
> that would source the normal 'check-patch.sh' and throw away the process
> return value.
This would eliminate the only benefit I see in having rawhide at all:
I'd like to see the rawhide job in RED if it is currently broken, so I
can look deeper to see why. If it's always green, it's useless to me.
However, if it is often red due to temporary unrelated changes, I
would not like it to block fixes.
But as you say, we can try it out and check the signal/noise ratio.I sent patches for ovirt-imageio, we need similar patches for vdsm.Piotr, can you handle this for vdsm?Nir