From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) by dpdk.org (Postfix) with ESMTP id 211012BB2 for ; Fri, 24 Feb 2017 14:07:24 +0100 (CET) Received: by mail-wm0-f44.google.com with SMTP id v77so13991246wmv.1 for ; Fri, 24 Feb 2017 05:07:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=UAU0n+vaSD3pzMcsxdROSXlmvfhH7LlNPCwT9fMw+4Y=; b=HNDeo965Pg1QUEMSWVrzPzHuZ4LE169736YQ8+5OZRRL9HE2Q3pIZksrkqEG5F9/07 4SoE8+tcRj0BN9F+U8Z5SZoGzefC8H6keUeIO7L3U1Ha9LQbIJk3IxWAofGGp3XTCkN8 X9HhCwY6Yac59OxBwsR8IQfYYv4NfXfrxO2ODPOYRKUnbPUTi4HQh7U61ARwQtVOc9P9 fDAAxG1EjOd4Vvb5TI+TphwiXV2qlO2WU6f1TPTsU9VOKZCtliE1QFFwRE0oXy1qTX1S bW7tQAjecTODyzzCWWLo8mE2UV4Lt+7lvlKIuaMd13cW66kGY+C8rMjtn469j2w8E6EG MkMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=UAU0n+vaSD3pzMcsxdROSXlmvfhH7LlNPCwT9fMw+4Y=; b=XnRlAAUTxioJxiqfHF7ff3CWuZ0SNMVqH8KyixPiPkuHt1XUCXaBFx3SlhE/7wUlPK O2u2+jHZ/Vy9cVemBrcWCZVVQrfQB87/EFVGjgzxTeLl7mqXOzdYSGcTydkPkcPr/Rwb t5S5lrUJ2miXhdhh+3IYvVsj1aSscA8DbM5RqnGPmSlZ890VADmFHlN54ygKRuMLp8Rw KX8xC5PgMEZ7ACrPQ72viJWhhjq3gwjtZjW28DEoiIKU3cJBhT7gidwxoL1uafUIW4O3 ee1V7F+zm81fGd/XbDRgusZc66K4M9Is5FJglmy373mL4/BHXdBzCcICvigBhI6UNyUv xEew== X-Gm-Message-State: AMke39m+JMJkVDAIgI0Vrtw5+q3HV+vNcLNCotKTBVAQ1Szf/GxWIOzFiZ9LOnx46jLGaEYJ X-Received: by 10.28.30.12 with SMTP id e12mr2787460wme.125.1487941643868; Fri, 24 Feb 2017 05:07:23 -0800 (PST) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id o26sm2236670wro.44.2017.02.24.05.07.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Feb 2017 05:07:23 -0800 (PST) From: Thomas Monjalon To: "Dumitrescu, Cristian" Cc: "Richardson, Bruce" , dev@dpdk.org Date: Fri, 24 Feb 2017 14:07:22 +0100 Message-ID: <1795016.0T9qy8tmF5@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D89126527526E0@IRSMSX108.ger.corp.intel.com> References: <59AF69C657FD0841A61C55336867B5B035B99794@IRSMSX103.ger.corp.intel.com> <1746585.AAhpvkiIzm@xps13> <3EB4FA525960D640B5BDFFD6A3D89126527526E0@IRSMSX108.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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:07:24 -0000 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