Re: [Announce] A new tree for vhost/virtio

[Tetsuya Mukawa <mukawa@igel.co.jp>]

On 2016/04/19 3:55, Yuanhan Liu wrote:
> 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?

Yes, could you please.

Thanks,
Tetsuya

>
> Thanks.
>
> 	--yliu
>
> ----- Forwarded message from Yuanhan Liu <yuanhan.liu@linux.intel.com> -----
>
> Date: Wed, 13 Apr 2016 01:53:41 +0800
> From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
> To: Thomas Monjalon <thomas.monjalon@6wind.com>
> Cc: Bruce Richardson <bruce.richardson@intel.com>, "Zhu, Heqing" <heqing.zhu@intel.com>,
> 	Yuanhan Liu <yuanhan.liu@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 -----