From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=VAm7a9KS90qAwnyeToi7kSR00zguoh9Pnyk+Ru10yok=; b=iCfXvFVkW9CMxsM9MFRUDLb27baKud5F4ajYr3Dzx2xAZeolHDgsLbiyn46A1KQnZN slaIjSLtiOhUjxtTmRuYzbw+WqSogn6rIwJEbfjk7BMkIPuJKFKEzzkd5d56npRCVXAW S1qKezq0Lsx0ZTL7Xvxjo9WRLDw5jh/2IP5/OM0PU72vEXUFSq0qcqBLl70TVNMWl9Do +DXiROiMKqKE7ucKP/JAt0pYuQIvQHlw0OygPaR/uRE2uE/WssHSPa///2xwaIRvMYbv I0Gds/rEoCudSwIegmrFcYeOZNsARqfCuB1MYC5WkravqDxPyiafwNXu6QeFu4i9H59R PPVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=VAm7a9KS90qAwnyeToi7kSR00zguoh9Pnyk+Ru10yok=; b=Kwj4yWawUF3Vo6E5OTPsqt8mpBDWASmoosrxNWG+6dkvRdSU1HqHCKg3JdWLe14yCQ Av+7BSWvBdKTtE9VCUt7nftkarB1IRkq55Lz1IIYn5e3gtycH4prr0BeQbZq210dAQH5 RmHFoDyqj8Vq5Zlep1mZwKjAtym/YEIRmusc3hlqZ50T0hYYnPMpVxh180fB1VI/Ot+y jNcKhpbL1NDLADhbi+7UBaQHX7ZOcCh+k1tHmuHfXASyAAYDAZHPD6lZkH7wCF0n/ayZ os0phLNz1yTo80Ru12FkrTZCNqn6hw7UyWM6ySnUKo8O6wQUzr9UsL21IPz7H4Db4lBO JyMA== X-Gm-Message-State: AKaTC00i3SJZD08U53BqjjPOibrzI0LP3U/MS5ErvPdgfXUCQtBqwzgl/TS8Z+hZkAPZhMdz X-Received: by 10.28.73.136 with SMTP id w130mr12274150wma.82.1479718424221; Mon, 21 Nov 2016 00:53:44 -0800 (PST) Received: from xps13.localnet (183.20.90.92.rev.sfr.net. [92.90.20.183]) by smtp.gmail.com with ESMTPSA id f126sm18161034wme.22.2016.11.21.00.53.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 21 Nov 2016 00:53:43 -0800 (PST) From: Thomas Monjalon To: Neil Horman Cc: dev@dpdk.org, "Mcnamara, John" Date: Mon, 21 Nov 2016 09:52:41 +0100 Message-ID: <1855350.07sWV4iMZa@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20161118161025.GC29049@hmsreliant.think-freely.org> References: <20161118161025.GC29049@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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: Mon, 21 Nov 2016 08:53:44 -0000 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.