All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fam Zheng <famz@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: Greg Kurz <groug@kaod.org>,
	kwolf@redhat.com, mst@redhat.com, jasowang@redhat.com,
	qemu-devel@nongnu.org, mreitz@redhat.com,
	aneesh.kumar@linux.vnet.ibm.com, stefanha@redhat.com,
	cornelia.huck@de.ibm.com, pbonzini@redhat.com
Subject: Re: [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination
Date: Thu, 22 Sep 2016 13:39:48 +0800	[thread overview]
Message-ID: <20160922053948.GD2115@lemon> (raw)
In-Reply-To: <808a38b4-cca6-5c1d-7f67-89c7b5538eba@redhat.com>

On Wed, 09/21 09:29, Eric Blake wrote:
> On 09/21/2016 09:01 AM, Fam Zheng wrote:
> > On Wed, 09/21 15:44, Greg Kurz wrote:
> >> On Wed, 21 Sep 2016 06:35:04 -0700 (PDT)
> >> no-reply@patchew.org wrote:
> >>
> >>> Hi,
> >>>
> >>> Your series failed automatic build test. Please find the testing commands and
> >>> their output below. If you have docker installed, you can probably reproduce it
> >>> locally.
> >>>
> >>
> >> Heh... of course patchew doesn't know about Stefan's series. :)
> > 
> > Usually those patchsets fail to apply and patchew keeps quiet. This series is
> > the first victim of a exception, seemingly. :)
> 
> While we're at it, is there a way to make the error messages include the
> last 15 lines or so of the build log first, and then the full build log?
>  Usually, the failure is easy to identify from the tail of the message,
> but having to scroll to the bottom past all the successful portion of
> the log is slower than seeing the tail up front.  At the same time, the
> full log is useful for the cases where the failure occurs earlier than
> the last 15 lines.

Scrolling to bottom is quite easy in any email client, while more sections in a
long email demand extra effort to manage and read. I doubt adding a "tail of
log" section just before the full log helps us much. I'd rather keep it simple
and stupid.

> 
> > 
> >>
> >> Is there an appropriate way to avoid complaints when sending a patchset that
> >> isn't based on QEMU master ?
> > 
> > Currently we don't, but we can invent one. Like:
> > 
> > Base: http://github.com/someone/qemu branch
> 
> I like that idea (these patches apply from that point; then it is up to
> patchew whether to bother chasing down that point or just skipping the
> series)
> 
> > 
> > for the "base on maintainer tree" case, or just inform patchew to "pull"
> > instead of apply:
> > 
> > Git: http://github.com/someone/qemu topic
> 
> Maybe Pull: instead of Git:, but again a nice idea.

I'm adding them to my list.

> 
> 
> > 
> > for the "base on the other series" case.
> > 
> > Supporting this is not complicated, the tricky thing is to remember to put that
> > magic in cover letters every time a series doesn't base on master.
> > 
> > Any thoughts on the harder question? :)
> 
> Which one was the harder question? How to get people to remember to use
> magic that patchew can recognize?

Yes. :)


> 
> -- 
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
> 

  reply	other threads:[~2016-09-22  5:40 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-21 13:13 [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination Greg Kurz
2016-09-21 13:14 ` [Qemu-devel] [PATCH 1/7] virtio-9p: handle handle_9p_output() error Greg Kurz
2016-09-21 14:16   ` Cornelia Huck
2016-09-21 14:38     ` Greg Kurz
2016-09-21 14:43       ` Cornelia Huck
2016-09-21 14:42     ` Greg Kurz
2016-09-21 13:14 ` [Qemu-devel] [PATCH 2/7] virtio-blk: handle virtio_blk_handle_request() errors Greg Kurz
2016-09-21 14:28   ` Cornelia Huck
2016-09-21 15:01     ` Greg Kurz
2016-09-21 13:14 ` [Qemu-devel] [PATCH 3/7] virtio-net: handle virtio_net_handle_ctrl() error Greg Kurz
2016-09-21 14:30   ` Cornelia Huck
2016-09-21 15:03     ` Greg Kurz
2016-09-21 13:14 ` [Qemu-devel] [PATCH 4/7] virtio-net: handle virtio_net_receive() errors Greg Kurz
2016-09-21 14:38   ` Cornelia Huck
2016-09-21 13:14 ` [Qemu-devel] [PATCH 5/7] virtio-net: handle virtio_net_flush_tx() errors Greg Kurz
2016-09-21 13:14 ` [Qemu-devel] [PATCH 6/7] virtio-scsi: convert virtio_scsi_bad_req() to use virtio_error() Greg Kurz
2016-09-21 13:14 ` [Qemu-devel] [PATCH 7/7] virtio-scsi: handle virtio_scsi_set_config() error Greg Kurz
2016-09-21 13:35 ` [Qemu-devel] [PATCH 0/7] virtio: avoid inappropriate QEMU termination no-reply
2016-09-21 13:44   ` Greg Kurz
2016-09-21 14:01     ` Fam Zheng
2016-09-21 14:29       ` Eric Blake
2016-09-22  5:39         ` Fam Zheng [this message]
2016-09-21 14:34       ` Greg Kurz
2016-09-21 17:38       ` Michael S. Tsirkin
2016-09-21 17:35     ` Michael S. Tsirkin
2016-09-21 18:12       ` Greg Kurz
2016-09-22  1:19 ` Gonglei
2016-09-22  6:43   ` Greg Kurz
2016-09-22  6:55     ` Gonglei (Arei)
2016-09-22  7:21       ` Greg Kurz
2016-09-22  7:30         ` Gonglei (Arei)
2016-09-22  7:38         ` Gonglei (Arei)
2016-09-22  8:14           ` Greg Kurz
2016-09-22  8:28             ` 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=20160922053948.GD2115@lemon \
    --to=famz@redhat.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=eblake@redhat.com \
    --cc=groug@kaod.org \
    --cc=jasowang@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /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.