From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: Proposal for a new Committer model Date: Mon, 21 Nov 2016 09:52:41 +0100 Message-ID: <1855350.07sWV4iMZa@xps13> References: <20161118161025.GC29049@hmsreliant.think-freely.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org, "Mcnamara, John" To: Neil Horman Return-path: Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) by dpdk.org (Postfix) with ESMTP id 911812BAC for ; Mon, 21 Nov 2016 09:53:44 +0100 (CET) Received: by mail-wm0-f46.google.com with SMTP id f82so131689669wmf.1 for ; Mon, 21 Nov 2016 00:53:44 -0800 (PST) In-Reply-To: <20161118161025.GC29049@hmsreliant.think-freely.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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. > 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. > 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. > 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 :) > 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.