From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) by dpdk.org (Postfix) with ESMTP id B595E2BB2 for ; Fri, 24 Feb 2017 14:17:34 +0100 (CET) Received: by mail-wm0-f49.google.com with SMTP id v77so14263776wmv.0 for ; Fri, 24 Feb 2017 05:17:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=hvq34sN1Z+52RCw9pP0l6++Tj4WGTjX1+CyBeZIICGQ=; b=OnmJ/NfxSSB7iadQgiy0ali2E1RrIE4PYgJ7HS68LJAjBBJTbFj2W8fQnJhpjW5pRJ WzswyDuZtQTsiCYowsyvS1REWSXOo652ISMAwMPT1/O0utMQap9KZUBqi2DDdrFITtAl O0nEVA3iEXw14IJz2PqxnOMNiG2eexcAza0SLzUXWfSJ71oZb/FMUADqHHgOFkAnj2Ek 7D9Pyvs3KXZOBBzK3wjjOmU2hJucm8rAeja6OtEy+7wibLXnfp1/JIXbWGRALUUTdsDy IC22T5cgclyNYxACngE1DlckAo/VejI4ACP2ZkCtecxcIcEUk/Rw3pkGE3y6ZWVbkfa8 B/+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=hvq34sN1Z+52RCw9pP0l6++Tj4WGTjX1+CyBeZIICGQ=; b=CHF3mYa1mrL3hFx392VQDSpUY57QMgW41YhltbiSjZWH58+K1InUlpogClWKQLE6Z6 Z+tlPezr0MBLomrAIJvCgm0BeTSj7SmythjOZaLVpnl+l+7hFT/LZ+cvSs6DrbHJLriP ccqyXte2w08I2LHdzq5Xsfj3RTwbYERpkDmtXwpDDLkGnXpfszp8S2PzrQe8MZJnkih7 pHnA7IGsljiyKe92ChRGgKflx8JQwWK8Ngvf2KmhW1upwD66+4TJM2q0/l8BrR/MHvGP n2BXo5d4/o/n/CPLTD2EER1r+wc9g0GHiwOHXX8Kkc6Uc5SFGMeCX7UeXjf5WvS+O/Xp hlCw== X-Gm-Message-State: AMke39m9ywo3tbjLAKGBSJuNWOY6NA1/cpuNPrCl7TKEU0ISp4X4/hp8he4n8sUGZkhWKZtJ X-Received: by 10.28.8.130 with SMTP id 124mr2478028wmi.65.1487942254472; Fri, 24 Feb 2017 05:17:34 -0800 (PST) Received: from platinum (2a01cb0c03c651000226b0fffeed02fc.ipv6.abo.wanadoo.fr. [2a01:cb0c:3c6:5100:226:b0ff:feed:2fc]) by smtp.gmail.com with ESMTPSA id i15sm2323570wmf.21.2017.02.24.05.17.34 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 24 Feb 2017 05:17:34 -0800 (PST) Date: Fri, 24 Feb 2017 14:17:31 +0100 From: Olivier Matz To: Remy Horton Cc: "Dumitrescu, Cristian" , Thomas Monjalon , "Richardson, Bruce" , "dev@dpdk.org" Message-ID: <20170224141731.25d7a618@platinum> In-Reply-To: <4322b761-83d7-2e23-5fdc-c5b493a95ca2@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> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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:34 -0000 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. That's why I think this is a decision that can be done by the technical board on a case by case basis. Olivier