Re: [PATCH v2 0/4] recipes for RPM packages

[Thomas Monjalon <thomas.monjalon-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>]

2014-05-01 06:28, Neil Horman:
> On Thu, May 01, 2014 at 08:53:02AM +0200, Thomas Monjalon wrote:
> > 2014-04-30 11:22, Neil Horman:
> > > On Wed, Apr 30, 2014 at 01:09:38PM +0200, Thomas Monjalon wrote:
> > > > The 4 spec files are used to build 4 different git trees with their
> > > > own
> > > > 
> > > > versioning:
> > > > 	http://dpdk.org/browse
> > > > 
> > > > So I think it's saner to keep them in their repository.
> > 
> > [...]
> > 
> > > Yeah, if they're separate git trees, they can be separate specs.  That
> > > said
> > > though, it strongly begs the question as to why you are keeping open
> > > source
> > > pmds outside of the dpdk library?  That really doesn't make much sense,
> > > whats preventing that integration (followed by the integration of the
> > > spec
> > > files)?
> > 
> > These extensions have their own versioning.
> 
> That doesn't seem to be a reason to keep them separately, in fact if
> anything its a reason to merge them so that versioning can be merged.
> 
> > They include PMD but also kernel modules (memnic and vmxnet3-usermap).
> 
> Thats nothing new.  The DPDK houses several PMD's that require kernel
> modules which are stored as part of the DPDK source tree, and built with it
> > In case of memnic, the kernel module is an alternative to DPDK PMD. So
> > there is no good reason to integrate it in DPDK.
> 
> I don't see what you're saying here.  Just because a given pmd offers an
> alternate implementation to simmilar functionality isn't  reason to keep
> them separate, its a reason to bring them together.  Users interested in
> one may well be interested in the other, and keeping them maintained
> together offers the opportunity to merge functionaty more readily. 
> Regardless of being maintained in one tree or two, they still offer the
> user the same thing, by maintaining them in the same tree you just offer
> the user a more convienient choice.
> > And it's better to host both
> > drivers together in order to keep coherency and share some resources.
> 
> Thats a reason to host them in the same tree, not just co-located on the
> same server.
> 
> > Extensions can also be a place to host some test applications related to
> > its PMD.
> 
> Once again, you already do this for the pmd's integrated to the dpdk in the
> examples directory, why not do it for the external pmds that you're also
> hosting?
> 
> > If you see DPDK as a framework, it's really logical to have repositories
> > hosting some projects which are (partly) using the framework.
> 
> By your reasoning, if I see DPDK as a framework, none of the PMDs should be
> integrated to the dpdk core repository because none of them use every aspect
> of the library.  You could certainly do this, and it would be an ok
> organization, but it would be a maintenece nightmare, because to update
> something in the core library that affected the pmd's would necessitate
> cloning N git trees for all the supported PMDs and updating them
> separately. No new contributors are going to want that headache.
> 
> All I'm saying here is, you've got several PMD's that are meant to be used
> with (and only with) the DPDK, you co-host them on the same git server,
> their licensing is compatible/identical, and you're maintaining them. 
> You're 95% of the way there, go the extra 5% and integrate them.  What you
> have currently is effectively 3 out of tree modules for your library.  As
> with any out of tree module, you'll find that, as you grow in contributors
> maintenece will lag on those modules, because contibutors wont know (or
> won't care) to go update the additional git trees.  It effectively marks
> them as second class citizens.
> 
> Neil

OK I understand you points and I suggest you to open a new thread about it in 
few weeks. At the moment, I prefer to concentrate efforts on release 1.6.0r2 
and opening version 1.7.0.

Thank you for your involvement
-- 
Thomas