Re: [dpdk-dev] dpdk: vhost/virtio staging/testing tree

[Yuanhan Liu <yuanhan.liu@linux.intel.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