* Re: [dpdk-dev] [Announce] A new tree for vhost/virtio
2016-04-18 18:55 ` [dpdk-dev] [Announce] A new tree for vhost/virtio Yuanhan Liu
@ 2016-04-19 2:46 ` Tetsuya Mukawa
2016-04-19 16:28 ` Victor Kaplansky
1 sibling, 0 replies; 3+ messages in thread
From: Tetsuya Mukawa @ 2016-04-19 2:46 UTC (permalink / raw)
To: Yuanhan Liu, dev
Cc: Thomas Monjalon, Bruce Richardson, Xie, Huawei, Victor Kaplansky,
Rich Lane, Stephen Hemminger, vincent.jardin, Wang, Zhihong, Tan,
Jianfeng
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 -----
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [dpdk-dev] [Announce] A new tree for vhost/virtio
2016-04-18 18:55 ` [dpdk-dev] [Announce] A new tree for vhost/virtio Yuanhan Liu
2016-04-19 2:46 ` Tetsuya Mukawa
@ 2016-04-19 16:28 ` Victor Kaplansky
1 sibling, 0 replies; 3+ messages in thread
From: Victor Kaplansky @ 2016-04-19 16:28 UTC (permalink / raw)
To: Yuanhan Liu; +Cc: dev
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 -----
>
^ permalink raw reply [flat|nested] 3+ messages in thread