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