From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas.monjalon@6wind.com>
Subject: Re: decision process to accept new libraries
Date: Fri, 24 Feb 2017 14:10:44 +0100
Message-ID: <2284716.crckWz010M@xps13>
References: <59AF69C657FD0841A61C55336867B5B035B99794@IRSMSX103.ger.corp.intel.com>
 <3EB4FA525960D640B5BDFFD6A3D89126527526E0@IRSMSX108.ger.corp.intel.com>
 <4322b761-83d7-2e23-5fdc-c5b493a95ca2@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>, "Richardson,
 Bruce" <bruce.richardson@intel.com>, dev@dpdk.org
To: Remy Horton <remy.horton@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wr0-f175.google.com (mail-wr0-f175.google.com
 [209.85.128.175]) by dpdk.org (Postfix) with ESMTP id 5C7802BB2
 for <dev@dpdk.org>; Fri, 24 Feb 2017 14:10:46 +0100 (CET)
Received: by mail-wr0-f175.google.com with SMTP id o22so7246441wro.1
 for <dev@dpdk.org>; Fri, 24 Feb 2017 05:10:46 -0800 (PST)
In-Reply-To: <4322b761-83d7-2e23-5fdc-c5b493a95ca2@intel.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

2017-02-24 11:33, Remy Horton:
> 
> 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.

Indeed, that's the idea: give more work to the maintainers and require less
work from occasional contributors.

It may be a good or wrong idea. Anyway it deserves to be discussed.