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

["Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>]

...<snip>

> The impact of having separate repositories is to reduce the work of a
> contributor touching many areas in a rework. This cost is transfered
> to the maintainer of the separate repository impacted by the change
> in the main repository. So it becomes this question:
> Do we prefer requiring some maintenance work from the contributors or
> from the maintainers?

IMO it is not fair for a contributor of the "main" repository to break stuff in other repos without fixing the other repos.

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). This is likely to lead to different release schedules for every of those "other" repos and big hassle in building a single unified DPDK release package. Or is it desired that DPDK release package should only contain the "main" repo?

What would be the advantages to this model, Thomas? And what are the issues with the current model of "you break it, you fix it"?