From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id B273E2BB0 for ; Wed, 23 Nov 2016 14:49:01 +0100 (CET) Received: from cpe-2606-a000-111b-40ed-7aac-c0ff-fec2-933b.dyn6.twc.com ([2606:a000:111b:40ed:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1c9Xux-0008FJ-0x; Wed, 23 Nov 2016 08:48:57 -0500 Date: Wed, 23 Nov 2016 08:48:45 -0500 From: Neil Horman To: Ferruh Yigit Cc: Thomas Monjalon , dev@dpdk.org, "Mcnamara, John" Message-ID: <20161123134845.GA6961@hmsreliant.think-freely.org> References: <20161118161025.GC29049@hmsreliant.think-freely.org> <1855350.07sWV4iMZa@xps13> <20161122195215.GA4463@hmsreliant.think-freely.org> <52ed2fa2-da41-1301-2d56-0fec05b79ce5@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52ed2fa2-da41-1301-2d56-0fec05b79ce5@intel.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-Spam-Score: -2.9 (--) X-Spam-Status: No 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 13:49:03 -0000 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? 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. 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). 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