From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id D4D035911 for ; Fri, 24 Feb 2017 14:17:46 +0100 (CET) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Feb 2017 05:17:44 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,201,1484035200"; d="scan'208";a="68643717" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.61]) by orsmga005.jf.intel.com with SMTP; 24 Feb 2017 05:17:43 -0800 Received: by (sSMTP sendmail emulation); Fri, 24 Feb 2017 13:17:42 +0000 Date: Fri, 24 Feb 2017 13:17:42 +0000 From: Bruce Richardson To: Thomas Monjalon Cc: "Dumitrescu, Cristian" , dev@dpdk.org Message-ID: <20170224131742.GA97552@bricha3-MOBL3.ger.corp.intel.com> References: <59AF69C657FD0841A61C55336867B5B035B99794@IRSMSX103.ger.corp.intel.com> <1746585.AAhpvkiIzm@xps13> <3EB4FA525960D640B5BDFFD6A3D89126527526E0@IRSMSX108.ger.corp.intel.com> <1795016.0T9qy8tmF5@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1795016.0T9qy8tmF5@xps13> Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.7.2 (2016-11-26) Subject: Re: [dpdk-dev] decision process to accept new libraries X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 13:17:47 -0000 On Fri, Feb 24, 2017 at 02:07:22PM +0100, Thomas Monjalon wrote: > 2017-02-22 19:06, Dumitrescu, Cristian: > > ... > > > > > 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 I think the reduction in work for new contributors is an admirable one. However, the idea of separating out libs to achieve this is not one I'm so sure about. My thinking is: * the examples, rather than the libs, might be a better source of "fat" to be cut. We're already looking at removing the old dpdk_qat sample, so perhaps more can follow that. * are library dependencies really that much an issue? * do we really want to make it that easy to change core library APIs? If the core library APIs change, that has an effect on everyone else using DPDK, so it's not an effort to be undertaken lightly. Having to change a bunch of other libraries and examples using that code will help contributors to understand a) what they are asking others to go through to update their own code for the change b) give insight into how the APIs are actually being used. Regards, /Bruce