From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 4E7843277 for ; Wed, 23 Nov 2016 17:21:03 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP; 23 Nov 2016 08:21:02 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,538,1473145200"; d="scan'208";a="1063328500" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.57]) ([10.237.220.57]) by orsmga001.jf.intel.com with ESMTP; 23 Nov 2016 08:21:01 -0800 To: Neil Horman References: <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> <20161123153341.GC6961@hmsreliant.think-freely.org> Cc: Thomas Monjalon , dev@dpdk.org, "Mcnamara, John" From: Ferruh Yigit Message-ID: Date: Wed, 23 Nov 2016 16:21:00 +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: <20161123153341.GC6961@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 16:21:05 -0000 On 11/23/2016 3:33 PM, Neil Horman wrote: > On Wed, Nov 23, 2016 at 02:01:44PM +0000, Ferruh Yigit wrote: >> 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. >> > Ok, glad that we're on the same page. > >> 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. >> > ok, I see what you're saying here, but I still don't see how this results in no > merge commits. From what I can see we have at least 4 subtrees (next-crypto, > next-net, next-eventdev, next-virtio). If you rebase all on lastest version of > thomas's tree, and then they all make changes and send a pull request, the first > to be merged will, by definition be a fast forward. The remaining three > however, cannot be, because the prior merge has advanced the HEAD commit in > Thomas's tree such that its divergent from the subsequent tree to be merged. So there > should be some merge commits in Thomas's tree. This is simple indeed, all can do fast-forward, because all sub-trees touch to different files. Currently: next-net: drivers/net/* [except virtio and vhost] next-crypto: drivers/crypto/* next-virtio: drivers/net/virtio/*, drivers/net/vhost/* Common files are in main tree, when all rebased on top of it, they all can be merged as fast-forward. > > The only way I see around that, is if the merges are serialized (i.e. if you > provide an order to the subtrees and each subtree rebases from thomas prior to > applying its patches, then merges back to thomas's tree). Thats rather defeating > of the purpose of parallel trees though. You can all rebase, but then you > operate independently of each other. Thats how we realize a speedup here > > > Neil >