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

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

2017-02-24 11:33, Remy Horton:
> 
> 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.

Indeed, that's the idea: give more work to the maintainers and require less
work from occasional contributors.

It may be a good or wrong idea. Anyway it deserves to be discussed.