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

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

[Yuanhan Liu]

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@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 -----

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

[Tetsuya Mukawa]

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 -----

Re: [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@linux.intel.com>
> To: dev@dpdk.org
> Cc: "Thomas Monjalon" <thomas.monjalon@6wind.com>, "Bruce Richardson" <bruce.richardson@intel.com>, "Huawei Xie"
> <huawei.xie@intel.com>, "Victor Kaplansky" <victork@redhat.com>, "Rich Lane" <rich.lane@bigswitch.com>, "Tetsuya
> Mukawa" <mukawa@igel.co.jp>, "Stephen Hemminger" <stephen@networkplumber.org>, "vincent jardin"
> <vincent.jardin@6wind.com>, "Zhihong Wang" <zhihong.wang@intel.com>, "Jianfeng Tan" <jianfeng.tan@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@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 -----
>