Re: [dpdk-dev] decision process to accept new libraries

[Olivier Matz <olivier.matz@6wind.com>]

On Fri, 24 Feb 2017 11:33:11 +0000, Remy Horton <remy.horton@intel.com>
wrote:
> On 22/02/2017 19:06, Dumitrescu, Cristian wrote:
> [..]
> > This essentially leads to the "other" repos becoming second class
> > citizens that can be broken at any time without prior notice or the
> > right to influence the change. The amount of maintenance work
> > becomes very difficult to quantify (e.g. we all know what a ripple
> > effect a chance in the mbuf structure can cause to any  of those
> > "other" DPDK libraries).  
> 
> +1 - In my experience anything other than a single repository ends up
> in tears sooner or later. At a previous company I worked on a project
> where each "module" went into its own repo, all fourty-five of which
> were strung together using Gerrit/Jenkins, the result being I spent
> more time on rebases and build breakages than writing business logic.
> Patchsets that cross repo boundaries are a recipe for pain, and if
> DPDK goes down the same route, it will likley cripple development.

On the other hand, I think we can agree that everything that depends on
dpdk cannot be hosted in dpdk repository.

Many applications are hosted in other repositories: for instance pktgen
or vpp. A given version of these applications runs on a given version of
dpdk. It could also applies for libraries.

Having apps/libs outside the dpdk repo is more work for their
maintainers because they may need to revalidate (compilation + test) for
each dpdk version. Having them inside the dpdk repo is more work for
the maintainers of dpdk core libs, because they need to update all of
them when they do a big changes. This is sometimes not doable because
they don't have a test platform or knowledge for each pmd or lib.

That's why I think this is a decision that can be done by the technical
board on a case by case basis.

Olivier