From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id 9B0D15598 for ; Wed, 16 Nov 2016 11:45:57 +0100 (CET) Received: by mail-wm0-f47.google.com with SMTP id a197so230527277wmd.0 for ; Wed, 16 Nov 2016 02:45:57 -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=Dusj5R8cFT98IrsAvbm8vvLAv9GuNJSwLFrFGT6dEls=; b=UcHVicK0GGnwokxr48A12cJbFYVHOd3og2Wf5WApR+7hxCQYNWBRNcK0rt0hau4X6I Px0a++DENhnWAYUd3EMxpyqYQVs7Mc+m3wfEhBMF7bBk3CtwfPYrYJwNsdCJpNAnCMXE jz8rS17BwXvis774lVnl4FMXV88AXZBnV54GT5uST2APPfrHorgMBSyoUB57M+pc6Iyd +PJo0c60tZiCnoRNBkz9wcO9P0A0EWLIfSQJPPhyIBF9mOeZ38Olc1TzfFhFxw6p84Yp eEtjecwA0VfroM2mDr7zc8PNZGXDYKYW+O77m29+zG4G1YVM0ASycb+kZv+/X2IHT4WP 1LEg== 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=Dusj5R8cFT98IrsAvbm8vvLAv9GuNJSwLFrFGT6dEls=; b=VDwcuUfx/bw4o8Zm/fZdYAP/gk3fpKvR2qTHujulMX3VdT08MhN0awC95idypSgfn8 YB07sApHgKyeK3xe0J4esOVuvhBojZ0I9Me4t1LtjTQ+LjlSGab4ZbSLKgZ005ei59Ke d8P5sP4Z4RPASuXobME5o+aBMp6hK14KNL6Y1+gpkZ0ZqSFsjpV+Rr7W6hyn7wnwbwY9 IUbE54tSMTiKrO+D45LlPvr3Q+pWHivkmidkI06+nt9AGVbak3bYNC3DRbegeJoCwwDV dxNr7DR9N5xUYNi0k8/bcaW/Dvb+gxfBfIIhlwVnTIG0FBXknIHejcDyOwQz/THgYIql d/zA== X-Gm-Message-State: ABUngvcfpWlM8R4cXrFwrzn8YzMkb5Myqth7nReNIKeaR31XojhCeI+xqR1uLeQfSef4iwDQ X-Received: by 10.28.157.137 with SMTP id g131mr8321263wme.29.1479293157297; Wed, 16 Nov 2016 02:45:57 -0800 (PST) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id j1sm21077000wjm.26.2016.11.16.02.45.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Nov 2016 02:45:56 -0800 (PST) From: Thomas Monjalon To: "Mcnamara, John" Cc: moving@dpdk.org, ferruh.yigit@intel.com, yuanhan.liu@linux.intel.com, pablo.de.lara.guarch@intel.com Date: Wed, 16 Nov 2016 11:45:55 +0100 Message-ID: <1660077.mdFWPiNUk9@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-moving] Proposal a Committer model X-BeenThere: moving@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK community structure changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 10:45:57 -0000 Hi, 2016-11-15 23:35, Mcnamara, John: > Hi, > > I'd like to propose a change to the DPDK committer model. > Currently we have one committer for the master branch of the DPDK project. Yes it's me. And we have three other committers (CC'ed) for the sub-trees dpdk-next-net, dpdk-next-virtio and dpdk-next-crypto. > One committer to master represents a single point of failure For the release 16.11, 49% of the patches were committed by me. Other patches came from sub-trees. > and at times can be inefficient. > There is also no agreed cover for times when the committer is > unavailable such as vacation, public holidays, etc. > I propose that we change to a multi-committer model for the DPDK > project. We should have three committers for each release that can > commit changes to the master branch. Most of the critical work is done in the sub-trees which cover every drivers. However I feel we could add more sub-trees and especially for EAL. Ideally, the master branch should just gather commits from the sub-trees. About long vacation, we may find backup committers for each git tree if it's really needed. > There are a number of benefits: > > 1. Greater capacity to commit patches. > 2. No single points of failure - a committer should always be > available if we have three. > 3. A more timely committing of patches. More committers should equal a > faster turnaround - ideally, maintainers should also provide feedback > on patches submitted within a 2-3 day period, as much as possible, > to facilitate this. > 4. It follows best practice in creating a successful multi-vendor > community - to achieve this we must ensure there is a level playing > field for all participants, no single person should be required to > make all of the decisions on patches to be included in the release. Committing faster means making patches disappear from the radar faster. It does improve neither the quality nor the multi-vendor cooperation. DPDK is mainly a community of hardware vendors. At the beginning, there was only one vendor (Intel). After being open on dpdk.org, more vendors joined. Nowadays we are still working to be more and more vendor neutral. Examples of current work: bus abstraction, filter API, event model, etc. I think there are two major issues when working on neutrality in DPDK: 1/ The first challenge and priority for a developer/vendor is to push access to new hardware features and achieving the best performance. It is not his priority to think about the genericity of the design or the API. And he generally doesn't take care of the performance on other hardware. 2/ There are not enough reviews to challenge genericity of developments. The only solution to these issues is to give some time for proper reviews. I would like to highlight again that having more good reviews is a good way of accelerating pace while improving quality. It is not so hard or long to commit patches which are ready. It is longer when the committer must play the reviewer role because of an obvious lack of review. About "no single person should be required to make all of the decisions on patches to be included in the release", I totally agree. That's why the reviews and discussions must make clear what is the consensus, the community decision. > Having multiple committers will require some degree of co-ordination > but there are a number of other communities successfully following > this model such as Apache, OVS, FD.io, OpenStack etc. so the approach > is workable. I won't play the game of listing and comparing other projects, though there are a lot (and famous) counter-examples. The other model is to promote some sub-trees. The current model pushes people to discuss and decide publicly. If we had a small committee of 3 persons coordinating to commit, it means they may are willing to take some decisions privately instead of relying on community consensus. And the risk is greater if these people are working for hardware vendors.