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

[Remy Horton <remy.horton@intel.com>]

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.