[dpdk-dev] [Announce] A new tree for vhost/virtio

[Victor Kaplansky]

Great!

Thanks a lot, the tree will allow me to focus on development, and not
waste the time on testing and maintenance.

-- 
Victor

----- Original Message -----
> From: "Yuanhan Liu" <yuanhan.liu at linux.intel.com>
> To: dev at dpdk.org
> Cc: "Thomas Monjalon" <thomas.monjalon at 6wind.com>, "Bruce Richardson" <bruce.richardson at intel.com>, "Huawei Xie"
> <huawei.xie at intel.com>, "Victor Kaplansky" <victork at redhat.com>, "Rich Lane" <rich.lane at bigswitch.com>, "Tetsuya
> Mukawa" <mukawa at igel.co.jp>, "Stephen Hemminger" <stephen at networkplumber.org>, "vincent jardin"
> <vincent.jardin at 6wind.com>, "Zhihong Wang" <zhihong.wang at intel.com>, "Jianfeng Tan" <jianfeng.tan at intel.com>
> Sent: Monday, April 18, 2016 9:55:06 PM
> Subject: [Announce] A new tree for vhost/virtio
> 
> 
> Hi,
> 
> Here I'd like to announce a new tree for vhost/virtio[0], and I'm
> going to be the maintainer.
> 
>     [0]: http://dpdk.org/browse/next/dpdk-next-virtio/
> 
> This is done by a private request to Thomas few days ago (well, I'd
> confess this should have been a public request/discussion, and you
> can find it in the end of this email).
> 
> And this is for merging patches a bit faster, especially for those
> fix and cleanup patches. Note that it still takes time to merge
> feature patches, even those from myself. Another note is that this
> tree is meant to be rebaseable.
> 
> You are suggested to make virtio/vhost patches based on this tree,
> to reduce patch conflict chance.
> 
> @Tetsuya, do you mind if I take over patches for vhost-pmd as well?
> 
> Thanks.
> 
> 	--yliu
> 
> ----- Forwarded message from Yuanhan Liu <yuanhan.liu at linux.intel.com> -----
> 
> Date: Wed, 13 Apr 2016 01:53:41 +0800
> From: Yuanhan Liu <yuanhan.liu at linux.intel.com>
> To: Thomas Monjalon <thomas.monjalon at 6wind.com>
> Cc: Bruce Richardson <bruce.richardson at intel.com>, "Zhu, Heqing"
> <heqing.zhu at intel.com>,
> 	Yuanhan Liu <yuanhan.liu at linux.intel.com>
> Subject: A request to take over vhost/virtio patches (was Re: [dpdk-dev]
> dpdk: vhost/virtio
> 	staging/testing tree)
> User-Agent: Mutt/1.5.23 (2014-03-12)
> 
> Hi Thomas,
> 
> Due to the nature of vhost/virtio (being open standard), we have more
> external contributors (not from intel) than other components: I just
> wrote a script to count that (the number means the # of contributors
> not from intel, and the date is got from this release only):
> 
>     vhost|virtio: 10
>     doc: 10
>     ethdev: 9
>     eal: 9
>     mlx: 8
>     mk: 7
>     mlx5: 6
>     app/test: 6
>     examples: 5
>     config: 5
>     tools: 4
>     mlx4: 4
>     eal/linux: 4
>     bonding: 4
>     vmxnet3: 3
>     nfp: 3
>     mbuf: 3
>     lpm: 3
>     ixgbe: 3
>     igb: 3
>     i40e: 3
> 
> As you can see, vhost/virtio is on the top of the list, which is a
> great thing: it means we have a health community. We have done well
> to achieve that, however, I'm thinking we could do better: to be
> more active on patch reviewing/merging, to try to solve some problems
> I found as I stated in my following email.
> 
> Therefore, I'd like to request again to take over all vhost/virtio
> patches. In another word, I'd like to maintain another tree, like
> Bruce does for dpdk-next-net tree, and to apply patches in time.
> 
> And now, I'd like to introduce myself a bit, and hopefully this
> could convince you that I'm competent to the committer role, though
> you might have already known that from my recent performs :)
> 
> I have been working on open source projects since 2009. Till now,
> it would be about 7 years of experience on open source. My first
> project was Syslinux, later on, I have worked on few more projects,
> including Linux Kernel, Mesa and so on. Therefore, I'm sure that
> my rich experience on open source would definitely let me be
> capable of the new role.
> 
> Thanks.
> 
> 	--yliu
> 
> 
> On Tue, Feb 16, 2016 at 12:02:42PM +0800, Yuanhan Liu wrote:
> > 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
> 
> ----- End forwarded message -----
>