From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 2059B2BB4 for ; Fri, 24 Feb 2017 14:25:50 +0100 (CET) Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga105.fm.intel.com with ESMTP; 24 Feb 2017 05:25:49 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,201,1484035200"; d="scan'208";a="69742698" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.61]) by fmsmga006.fm.intel.com with SMTP; 24 Feb 2017 05:25:47 -0800 Received: by (sSMTP sendmail emulation); Fri, 24 Feb 2017 13:25:46 +0000 Date: Fri, 24 Feb 2017 13:25:46 +0000 From: Bruce Richardson To: Olivier Matz Cc: Remy Horton , "Dumitrescu, Cristian" , Thomas Monjalon , "dev@dpdk.org" Message-ID: <20170224132546.GB97552@bricha3-MOBL3.ger.corp.intel.com> References: <59AF69C657FD0841A61C55336867B5B035B99794@IRSMSX103.ger.corp.intel.com> <3736276.ftqFo2Af7c@xps13> <20170221134658.GA208676@bricha3-MOBL3.ger.corp.intel.com> <1746585.AAhpvkiIzm@xps13> <3EB4FA525960D640B5BDFFD6A3D89126527526E0@IRSMSX108.ger.corp.intel.com> <4322b761-83d7-2e23-5fdc-c5b493a95ca2@intel.com> <20170224141731.25d7a618@platinum> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170224141731.25d7a618@platinum> 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:25:51 -0000 On Fri, Feb 24, 2017 at 02:17:31PM +0100, Olivier Matz wrote: > On Fri, 24 Feb 2017 11:33:11 +0000, Remy Horton > wrote: > > 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. > > On the other hand, I think we can agree that everything that depends on > dpdk cannot be hosted in dpdk repository. > > Many applications are hosted in other repositories: for instance pktgen > or vpp. A given version of these applications runs on a given version of > dpdk. It could also applies for libraries. > > Having apps/libs outside the dpdk repo is more work for their > maintainers because they may need to revalidate (compilation + test) for > each dpdk version. Having them inside the dpdk repo is more work for > the maintainers of dpdk core libs, because they need to update all of > them when they do a big changes. This is sometimes not doable because > they don't have a test platform or knowledge for each pmd or lib. Maybe not, and I wouldn't expect someone making a change to have to test every library affected by the change. However, I would expect them to have enough knowledge of the change being made to update the affected code in other libraries in a semi-mechanical way, and ensure it compiles. If you are changing a core library and are not able to change all uses of the API yourself, then you really need to question if the change is a good one or not, or if you are qualified to make a change if you don't understand how the old code was being used. I also think it's likely that many users of DPDK code will have legacy code using DPDK, for which the original programmer may be the one making any updates. If, again, the change is such that it can't be done in a relatively mechanical way, that is going to be a problem for all those users. As for review and testing, that is the responsibility of the maintainers and validators responsible for the individual library being updated. /Bruce