[dpdk-dev] decision process to accept new libraries
Remy Horton
remy.horton at intel.com
Fri Feb 24 12:33:11 CET 2017
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.
More information about the dev
mailing list