From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 29AA2106A for ; Tue, 22 Nov 2016 21:56:26 +0100 (CET) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga105.jf.intel.com with ESMTP; 22 Nov 2016 12:56:25 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,682,1473145200"; d="scan'208";a="33565783" Received: from mchokshi-mobl1.ger.corp.intel.com (HELO [10.252.12.4]) ([10.252.12.4]) by orsmga004.jf.intel.com with ESMTP; 22 Nov 2016 12:56:24 -0800 To: Neil Horman , Thomas Monjalon References: <20161118161025.GC29049@hmsreliant.think-freely.org> <1855350.07sWV4iMZa@xps13> <20161122195215.GA4463@hmsreliant.think-freely.org> Cc: dev@dpdk.org, "Mcnamara, John" From: Ferruh Yigit Message-ID: <52ed2fa2-da41-1301-2d56-0fec05b79ce5@intel.com> Date: Tue, 22 Nov 2016 20:56:23 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161122195215.GA4463@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: Tue, 22 Nov 2016 20:56:27 -0000 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. 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. > > >>> 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. Also with current process, after -rc2 release, patches directly merged into main tree instead of sub-trees... > >>> Thomas in turn should by and large, >>> only be integrating pull requests. This should address our high- >>> throughput issue, in that it will allow multiple maintainers to share the >>> workload, and integration should be relatively easy. >> >> Yes in an ideal organization, the last committer does only a last check >> that technical plan and fairness are respected. >> So it gives more time to coordinate the plans :) >> > Correct. Thats never 100% accurate of course, some things will still have to > come to you directly, simply by virtue of the fact that they don't completely > fit anywhere else, but thats ok, the goal is really just to get your total patch > volume lower, and replace it with pull requests that you can either trivialy > mere or figure out with the help of the subtree maintainer. > >>> B) Designate alternates to serve as backups for the maintainer when they >>> are unavailable. This provides high-availablility, and sounds very much >>> like your proposal, but in the interests of clarity, there is still a >>> single maintainer at any one time, it just may change to ensure the >>> continued merging of patches, if the primary maintainer isn't available. >>> Ideally however, those backup alternates arent needed, because most of the >>> primary maintainers work in merging pull requests, which are done based on >>> the trust of the submaintainer, and done during a very limited window of >>> time. This also partially addreses multi-vendor fairness if your subtree >>> maintainers come from multiple participating companies. >> >> About the merge window, I do not have a strong opinion about how it can be >> improved. However, I know that closing the window too early makes developer >> unhappy because it makes wait - between development start and its release - >> longer. > > This is a fair point, but I'm not talking about closing it early here, all > I'm suggesting is that, if you do proper pull requests from subtrees, your tree > Thomas will only need a reasonably small window of time to accept new features, > because you'll just merge the subtrees, rather than integrating individual > patches. E.g. you won't be constantly merging patches over the course of a > development cycle, your tree's HEAD will mostly consist of merge commits as > subtree maintainers send you pull requests, and ideally they will send those > near the start of a window. How long you keep your merge window open after that > is up to you. > > Neil > > > >>