All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
To: Victor Kaplansky <victork@redhat.com>
Cc: dev@dpdk.org, "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: dpdk: vhost/virtio staging/testing tree
Date: Tue, 16 Feb 2016 12:02:42 +0800	[thread overview]
Message-ID: <20160216040242.GF21426@yliu-dev.sh.intel.com> (raw)
In-Reply-To: <20160212135131-mutt-send-email-victork@redhat.com>

On Fri, Feb 12, 2016 at 01:54:21PM +0200, Victor Kaplansky wrote:
> Hi!

Hi Victor,

> Since I was maintaining an internal tree with patches related to
> vhost/virtio, I decided to make this staging tree public. It is
> useful to me and I hope it will be useful to others.
> 
> Collecting patches like this allows tracking dependencies between
> patches, their improvement etc. I also rebase the tree so
> contributors don't have to.

I had same thoughts, before, aiming to speed the patch review and
merge process.

DPDK community, likely, has a culture of very slow patch review and
merge process: I often saw patches not get reviewed for weeks, even
months! I also saw that a patch has been ACK-ed, but not get merged
until few weeks has been passed. While I am inside the team, I
understand it's a very reasonable phenomenon: every one of us has
lots of tasks to do, and we intend to do the review after all tasks
have been finished.

Despite the fact, I was thinking that I could maintain a tree, so
that I could apply all virtio/vhost patches that has been ACKed in
the first time. Later, I will send pull request to Thomas, from
time to time. Thomas, on the other hand, only need to have a double
check of the patches from my request. If he has any concerns on
some specific patch (or patch set), I will drop them, and let the
author to send a new version.

Put simply, it's a similar style Linux kernel (and QEMU) takes.

Another thing worthy noting is that Bruce started to maintain
a such tree recently:

    http://dpdk.org/browse/next/dpdk-next-net/

So, as long as Bruce merges patches quickly, it should not matter.

> Before publishing, I test the tree so it can serve as a known
> good state for people interested in preliminary testing of
> patches that aren't yet upstream, improving testing/validation as
> multiple people can test the same code.

I was thinking to build a very rough and simple test bot to
achieve that; however, no time for that.

	--yliu

      reply	other threads:[~2016-02-16  4:03 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-12 11:54 dpdk: vhost/virtio staging/testing tree Victor Kaplansky
2016-02-16  4:02 ` Yuanhan Liu [this message]

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=20160216040242.GF21426@yliu-dev.sh.intel.com \
    --to=yuanhan.liu@linux.intel.com \
    --cc=dev@dpdk.org \
    --cc=mst@redhat.com \
    --cc=victork@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.