qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Status and RFC of patchew testings on QEMU


From: Thomas Huth
Subject: Re: [Qemu-devel] Status and RFC of patchew testings on QEMU
Date: Mon, 17 Jul 2017 11:41:38 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0

On 17.07.2017 08:35, Fam Zheng wrote:
> Hi all,
> 
> Today I've included a fourth type of the automatic patchew replies: FreeBSD.
> 
> So far we have these tests running by patchew on each patch series:
> 
>   * Docker tests
>     Basically it is
>         make address@hidden \
>              address@hidden \
>              address@hidden"
> 
>   * checkpatch.pl
>     Each patch is fed to ./scripts/checkpatch.pl and all errors are reported.
> 
>   * s390x
>     It runs on a machine shared by Fedora team, basically only "./configure 
> and
>     make", because "make check" hanging is tricky to deal with from an
>     automation perspective. (Ideas?)

Is there any check that could hang "forever"? I think most of the checks
should have a proper timeout of one or two minutes, don't they?

Maybe you could also simply run the "make check" with the "timeout"
command to avoid that it hangs forever?

>   * FreeBSD
>     Like s390x.
> 
> Q1: In the worst case, you get four individual auto replies from patchew. Is
> that too many? Do you prefer one reply with all the results concatenated into
> one?

One result would be nicer, I think.

> Q2: Some think the full log in the mail body is more than necessary. Is it
> better or worse if it is a "tail -n 200" of the log in the body and the full 
> log
> attached?
> 
> Q3: What other tests do maintainers want? Different hosts? Different configure
> combinations?

Not sure, but should we maybe also check compiling with the configure
switches set to non-default values? E.g. --enable-debug --disable-slirp
--enable-tcg-interpreter --disable-tcg etc. ?

 Thomas



reply via email to

[Prev in Thread] Current Thread [Next in Thread]