2017-02-22 19:06, Dumitrescu, Cristian: > ...<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.
The question is "is it fair to ask a contributor to fix every libraries using a core one?" > 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? Yes the idea is to have a core package of 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"? That's a very good question Cristian. As said above, it is a matter of deciding the scope of responsibility of a contributor to a core library, or saying it differently, who should do the work on other libs and multiple examples? About the advantages, I think it could ease the contributions on core libraries and let people who are not full-time on DPDK to contribute to the core libraries. That's a real question and feedbacks are very welcome. I'd like to read opinions of more contributors. Thanks
