From: "Daniel P. Berrange" <berrange@redhat.com>
To: Fam Zheng <famz@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Status and RFC of patchew testings on QEMU
Date: Mon, 17 Jul 2017 11:02:06 +0100 [thread overview]
Message-ID: <20170717100206.GF3640@redhat.com> (raw)
In-Reply-To: <20170717063521.GA7393@lemon>
On Mon, Jul 17, 2017 at 02:35:21PM +0800, 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 docker-test-quick@centos6 \
> docker-test-build@min-glib \
> docker-test-mingw@fedora"
>
> * 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?)
>
> * 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?
The risk with combining everything into one reply is that if only one of the
four test systems fails / hangs / gets very backlogged, you're going to
delay reporting of failures from all four systems. Personally, I would like
to see any failure reported as soon as it happens, without waiting to see
if other things fail or pass.
> 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?
The mails are rather large alredy. It is common with Jenkins to only report
the tail of the logs, and then provide a hyperlink to a web site with the
complete log. This avoids bloating everyone's INBOXs with many 100 KB of
logs.
> Q3: What other tests do maintainers want? Different hosts? Different configure
> combinations?
>
> Q4: Any other improvements/features you want? (E.g. some documentation? :)
Sometimes the test system seems to get pretty backlogged and there's no
way of knowing this, as its indistinguishable from the situation where
it doesn't send results because everything passed.
I'd like to see a web page that provides a list of all mail threads that
the test system has queued, with status of which jobs and running, and
once completed, provides the full logs.
That way we can quickly check whether patchw has started processing a
particular series or not.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2017-07-17 10:02 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-17 6:35 [Qemu-devel] Status and RFC of patchew testings on QEMU Fam Zheng
2017-07-17 9:05 ` Stefan Hajnoczi
2017-07-17 9:28 ` Peter Maydell
2017-07-17 9:39 ` Fam Zheng
2017-07-17 10:06 ` Peter Maydell
2017-07-17 10:26 ` Daniel P. Berrange
2017-07-25 9:58 ` Peter Maydell
2017-07-27 11:03 ` Fam Zheng
2017-07-27 11:30 ` Gerd Hoffmann
2017-07-17 10:03 ` Daniel P. Berrange
2017-07-17 9:41 ` Thomas Huth
2017-07-17 10:20 ` Daniel P. Berrange
2017-07-17 11:00 ` Peter Maydell
2017-07-17 11:06 ` Daniel P. Berrange
2017-07-28 5:59 ` Philippe Mathieu-Daudé
2017-07-17 23:17 ` Fam Zheng
2017-07-18 9:11 ` Thomas Huth
2017-07-18 9:37 ` Peter Maydell
2017-07-18 9:42 ` Daniel P. Berrange
2017-07-19 7:46 ` Fam Zheng
2017-07-17 10:02 ` Daniel P. Berrange [this message]
2017-07-21 3:24 ` Fam Zheng
2017-07-17 10:39 ` Kevin Wolf
2017-07-17 10:49 ` Peter Maydell
2017-07-17 11:31 ` Kevin Wolf
2017-07-17 13:40 ` Max Reitz
2017-07-28 5:56 ` Philippe Mathieu-Daudé
2017-07-17 23:28 ` Fam Zheng
2017-07-18 10:14 ` Daniel P. Berrange
2017-07-28 5:46 ` Philippe Mathieu-Daudé
2017-07-28 6:33 ` Fam Zheng
2017-07-28 7:18 ` Cornelia Huck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170717100206.GF3640@redhat.com \
--to=berrange@redhat.com \
--cc=famz@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.