From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <ferruh.yigit@intel.com> Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 87949379B for <dev@dpdk.org>; Wed, 23 Nov 2016 15:01:47 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP; 23 Nov 2016 06:01:46 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,538,1473145200"; d="scan'208";a="8437070" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.57]) ([10.237.220.57]) by orsmga002.jf.intel.com with ESMTP; 23 Nov 2016 06:01:45 -0800 To: Neil Horman <nhorman@tuxdriver.com> References: <B27915DBBA3421428155699D51E4CFE202661F22@IRSMSX103.ger.corp.intel.com> <20161118161025.GC29049@hmsreliant.think-freely.org> <1855350.07sWV4iMZa@xps13> <20161122195215.GA4463@hmsreliant.think-freely.org> <52ed2fa2-da41-1301-2d56-0fec05b79ce5@intel.com> <20161123134845.GA6961@hmsreliant.think-freely.org> Cc: Thomas Monjalon <thomas.monjalon@6wind.com>, dev@dpdk.org, "Mcnamara, John" <john.mcnamara@intel.com> From: Ferruh Yigit <ferruh.yigit@intel.com> Message-ID: <a62396ac-dbb2-0a0c-dee6-ecb9bdbf0c8c@intel.com> Date: Wed, 23 Nov 2016 14:01:44 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <20161123134845.GA6961@hmsreliant.think-freely.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] Proposal for a new Committer model 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: Wed, 23 Nov 2016 14:01:48 -0000 On 11/23/2016 1:48 PM, Neil Horman wrote: > On Tue, Nov 22, 2016 at 08:56:23PM +0000, Ferruh Yigit wrote: >> On 11/22/2016 7:52 PM, Neil Horman wrote: >>> On Mon, Nov 21, 2016 at 09:52:41AM +0100, Thomas Monjalon wrote: >>>> 2016-11-18 13:09, Neil Horman: >>>>> A) Further promote subtree maintainership. This was a conversation that I >>>>> proposed some time ago, but my proposed granularity was discarded in favor >>>>> of something that hasn't worked as well (in my opinion). That is to say a >>>>> few driver pmds (i40e and fm10k come to mind) have their own tree that >>>>> send pull requests to Thomas. >>>> >>>> Yes we tried this fine granularity and stated that it was not working well. >>>> We are now using the bigger granularity that you describe below. >>>> >>> Ok, thats good, but that must be _very_ new. Looking at your git tree, I see no >>> merge commits. How are you pulling from those subtrees? >> >> next-net tree is active for last three releases. >> > What!? What is the purpose of holding patches in a subtree for multiple > releases? :) Of course not holding them in the sub-tree. Briefly, process is: - sub-tree gets patches during merge window - sub-tree first merged into main tree in -rc1 and later in -r2 next-net tree is actively in use for last three releases, and driver/net patches delegated to this tree. You can see different commiters in main tree. > If a given changeset isn't ready for merge to Thomas tree the people > working on it should clone the subtree to some place they can all collaborate on > it. Once it goes into a subtree there needs to be a defined workflow to get it > into the canonical tree that Thomas maintains on a regular, short time frame. > to do less is to confuse the process for everyone involved, and slow people > down, rather than accelerate their work. > >> I guess following is the first commit to the sub-tree: >> http://dpdk.org/ml/archives/dev/2016-February/032580.html >> >> sub-trees rebase on top of main tree regularly, that is why there is no >> merge commit. >> > I'm not asking about merge commits in the sub-tree, I'm asking about merge > commits in thomas's tree. Same, talking about Thomas' tree. > There should be a merge commit every time he pulls > from a sub-tree (unless its a fast-forward I think, but with multiple subtrees > and commits going to thomas directly, that should never really happen). That is what happening. Since sub-tree's rebase on top of main tree, when Thomas merges, it is just plain fast-forward. So it is allowed to re-write to history in sub-trees. > I don't > see any Merge commits in the master branch of his tree, so I'm left wondering > what mechanic is being used to migrate patches from net-next or crypo-next to > his tree. Thomas, can you comment here? > >>> >>> >>>>> We should be sharding that at a much higher >>>>> granularity and using it much more consistently. That is to say, that we >>>>> should have a maintainer for all the ethernet pmds, and another for the >>>>> crypto pmds, another for the core eal layer, another for misc libraries >>>>> that have low patch volumes, etc. >>>> >>>> Yes we could open a tree for EAL and another one for the core libraries. >>>> >>> That could be worthwhile. Lets see how the net and crypto subtrees work out >>> (assuming again that these trees are newly founded) >>> >>> >>>>> Each of those subdivisions should have >>>>> their own list to communicate on, and each should have a tree that >>>>> integrates patches for their own subsystem, and they should on a regular >>>>> cycle send pull requests to Thomas. >>>> >>>> Yes I think it is now a good idea to split the mailing list traffic, >>>> at least for netdev and cryptodev. >>>> >>> Agreed, that serves two purposes, it lowers the volume for people with a >>> specific interest (i.e. its a rudimentary filter), and it avoids confusion >>> between you and the subtree maintainer (that is to say, you don't have to even >>> consider pulling patches that go to the crypo and net lists, you just have to >>> trust that they pull those patches in and send you appropriate pull requests). >> >> I still find single mail list more useful. > Why? If you have interest in all the subsystems of a project, then its a small > amount of overhead to subscribe to a set of mailing lists and dump them all to a > single mail folder. If you only have interest in a subset, its much more > difficult to filter them out, given that we have a plethora of prefix tags for > patches to define subsystems that aren't always used consistently. Given that > this thread is here because we've identified the patch volume as a problem, it > seems fragmenting the list is the better solution. > >> Also with current process, after -rc2 release, patches directly merged >> into main tree instead of sub-trees... >> > Thats fine, at that point, if everything works properly, Thomas should only be > getting low volume patch flow for stabilization/bug fixing. If thats not the > case, then perhaps we need to consider doing extra merges from the subtrees > later in the cycle. > > Neil >