Re: [dpdk-dev] Why nothing since 1.8.0?

[Thomas Monjalon <thomas.monjalon@6wind.com>]

2015-01-15 08:06, Neil Horman:
> On Thu, Jan 15, 2015 at 10:51:38AM +0100, Thomas Monjalon wrote:
> > 2015-01-15 04:27, Ouyang, Changchun:
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Zhang, Helin
> > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Neil Horman
> > > > > On Wed, Jan 14, 2015 at 12:23:52PM -0800, Stephen Hemminger wrote:
> > > > > > Ok, so 1.8.0 came out almost a month ago and none of the patches
> > > > > > that were deferred waiting for the release got merged since then.
> > > > > > Last commit in git is the 1.8.0 release.
> > > > > >
> > > > > > Where is the post-merge window bundle, where are the later commits?
> > > > > > Lots of patches are sitting rotting in patchwork...
> > > > >
> > > > > +1, I've had the same questions.
> > > > > Neil
> > > > 
> > > > +1, Some patch set might be ready for being merged.
> > > 
> > > +1,  the earlier some patches are merged into mainline, and the easier those
> > > sequent patch sets can resolve their conflicts.
> > 
> > +1, there are some patches which are properly reviewed
> > 
> > Reminder: sub-tree to manage specific part of DPDK can be open on request
> 
> Ok, I think what you're saying here is you're too busy to handle all the patches
> comming in at the moment.  As such I'd like to propose a sub-tree encompassing
> all the pmds in DPDK.  I would envision that including all the acutal pmd's in
> the tree, as well as the infrastructure that is used to interface them to the
> core (i.e. the ethdev/rte_ether library).  I'll gladly maintain the patch pool
> and send you pull requests.

The list of PMDs is increasing:
	librte_pmd_af_packet
	librte_pmd_bond
	librte_pmd_e1000
	librte_pmd_enic
	librte_pmd_i40e
	librte_pmd_ixgbe
	librte_pmd_pcap
	librte_pmd_ring
	librte_pmd_virtio
	librte_pmd_vmxnet3
	librte_pmd_xenvirt
There is already some sub-trees for bnx2x, fm10k and i40e:
	http://dpdk.org/browse/

> If you could set me up with a login to dpdk.org, I'd appreciate it.

It is preferred to have 1 sub-tree per module.
What do you think of managing contributions for af_packet and/or virtio?
It would make sense as virtio is a RedHat technology.
Maybe it could include vhost lib and example.

Thanks for proposing
-- 
Thomas