From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <mhall@mhcomputing.net>
Received: from mail.mhcomputing.net (master.mhcomputing.net [74.208.46.186])
 by dpdk.org (Postfix) with ESMTP id BCE691288
 for <dev@dpdk.org>; Fri, 16 Jan 2015 02:48:49 +0100 (CET)
Received: by mail.mhcomputing.net (Postfix, from userid 1000)
 id 3EC5780C79B; Thu, 15 Jan 2015 17:46:26 -0800 (PST)
Date: Thu, 15 Jan 2015 17:46:26 -0800
From: Matthew Hall <mhall@mhcomputing.net>
To: "O'driscoll, Tim" <tim.o'driscoll@intel.com>
Message-ID: <20150116014626.GA14696@mhcomputing.net>
References: <20150114122352.63ef79eb@urahara> <1717148.0lUn7GOqmp@xps13>
 <20150115130616.GA22455@hmsreliant.think-freely.org>
 <12253538.YOLaLVcskf@xps13>
 <20150115185112.GC22455@hmsreliant.think-freely.org>
 <26FA93C7ED1EAA44AB77D62FBE1D27BA54C9978E@IRSMSX102.ger.corp.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <26FA93C7ED1EAA44AB77D62FBE1D27BA54C9978E@IRSMSX102.ger.corp.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] Why nothing since 1.8.0?
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <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>
X-List-Received-Date: Fri, 16 Jan 2015 01:48:50 -0000

On Thu, Jan 15, 2015 at 09:55:00PM +0000, O'driscoll, Tim wrote:
> As you said, there's a balance to be struck, and too many subtrees may 
> become unmanageable. With respect to your concern about developers having to 
> potentially develop patches against multiple subtrees, this has never been 
> raised as a concern by any of our development team. Is there any historical 
> data on the number of changes that would fall into this category so we can 
> see if it's a real problem or not?

Hi Tim,

What happens when a core API like rte_mbuf gets some changes, and you have to 
update the PMD's to fit?

Do I have to make 10-20 odd random patches to separate PMD maintainers instead 
of one set of patches to the PMD subtree?

To me it doesn't sound very nice for the guys maintaining the core. Given most 
of the changes seem to be mbuf or eal this seems like a scaling issue to me.

But maybe I misunderstood the process.

Matthew.