From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by dpdk.org (Postfix) with ESMTP id 8139E8E85 for ; Mon, 12 Oct 2015 12:48:00 +0200 (CEST) Received: by wicgb1 with SMTP id gb1so45234109wic.1 for ; Mon, 12 Oct 2015 03:48:00 -0700 (PDT) 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:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=D8/3tGOCjrGuxX0SO63dyEPC98NIeu8yYqx58OP4jtE=; b=Q1Edd8nQ/TNMb3983FOR3n211S28ecDt949+yZQHu9zzHKyk8QQkuK+OAs8tWMghZa Y2g8aS205B5XUI3NGRhw4A+uNwqFFS2O72Fezo82Ta0vIlXFtl39kOS6IkoKg7H+KAmJ ez04LB7dFwGwH8w2HJYQJIQROxYg+WsLKwXOZ3o6UoAt8fzCP4pS/4+pW3qZRIt9uoZf VX3J4cz0VSbB+VGxnjRKeIqq5O4eXUTGyMTmVdZI//rP4p2V32d4vyrdfB1MKofQOtAS 51LkBIotHjYH2qJ7f7wCdOepYst8ayCXoDeTmUsNw0HPZE4hSQcgJkMuxLcPIauAsSGU lajA== X-Gm-Message-State: ALoCoQndzeINCL8kCRn8nHony49VZmreYJutJTDsajw4Vek1I7bFXohnb7rslwuuGA9fBteEQq9M X-Received: by 10.194.216.228 with SMTP id ot4mr25174506wjc.156.1444646880163; Mon, 12 Oct 2015 03:48:00 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by smtp.gmail.com with ESMTPSA id s16sm10358059wik.16.2015.10.12.03.47.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Oct 2015 03:47:59 -0700 (PDT) From: Thomas Monjalon To: dev@dpdk.org Date: Mon, 12 Oct 2015 12:46:55 +0200 Message-ID: <6421280.5XkMhqyP4M@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <5619AF06.8070806@redhat.com> References: <5619AF06.8070806@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] Notes from project governance meeting at DPDK Userspace 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, 12 Oct 2015 10:48:00 -0000 Thanks Dave for the good summary. Some comments below. 2015-10-11 01:36, Dave Neary: > Keith raised the issue of general throughput of patches, and the number > of unreviewed/wait state patches: need to actively scale the process. > > Stephen: How about identifying reviewers, and Thomas designates lead > reviewer for each patch? Allows scaling of review, while allowing Thomas > to have last word. Alternative proposals are to have joint "maintainers" > all of whom can commit patches, subject to certain constraints (don't > commit your own code), or subsystem maintainers, establishing a > hierarchy of trust so that Thomas can just scan and accept reviews 90% > of the time. > > Thomas: Need many reviewers, but there should be one committer per tree. Some maintainers are already identified in this file: http://dpdk.org/browse/dpdk/tree/MAINTAINERS It is expected that the maintainers review every patches touching their area (with exceptions for minor changes). They should also participate in discussions to get consensus. Reviews from non-maintainers are also very welcome. Important features and fixes which are not properly reviewed should not be integrated. Someone in the room said it is the role of the patch author to get a review. I agree. Until now, patches from maintainers were accepted even if not reviewed. Should it be changed? In order to scale, some maintainers could become committers of a sub-tree. The granularity of the sub-trees can evolve with growth of the project. It seems a good idea to start with trees for drivers/net, drivers/crypto and packet framework. It is not clear yet how EAL and core libraries can benefit from any sub-tree. > Chris: Do we have enough ppl with skills to be reviewers? If not, how do > we get to that point? Contributors must be motivated enough to get some time and, in some cases, to get the green light from their management. Some private discussions revealed that the lack of involvement is often due to some management issues. > Venky: Performance requires a specific skill set, not everyone has the > skills, but slow patch review has an opportunity cost, and we can > minimise cost of "bad" reviews with good CI performance tests that catch > regressions Yes having a good distributed CI will help. But it cannot replace reviews for the quality and design considerations. > How do we maintain review velocity when maintainer is unavailable (eg. > on vacation)? How does it happen in Linux? > > - Linus delegates - names "locum" maintainer while he is away. Stephen > volunteered to do it for a week or two when necessary. Thanks Stephen. > Thomas: Subsystem maintainers carry review weight when maintainer is out. > Stephen: Subsystem maintainers are reviewers, need high level of trust > to be a top level maintainer. Having a -next tree is another way of basing its work on an up-to-date tree without waiting reviews. > Thomas - Subtrees can live in DPDK git tree, makes it easier to manage > merges afterwards. 2 volunteer subtree maintainers - Declan for crypto, > Kevin for (not noted). Is it an issue if only Intel people are subtree > maintainers? Venky: Yes, should have others. About company sharing: it would be very nice to have more patches reviewed by someone working for a different company than the author's one. Considering making at least one review, when waiting for integration of its patch, would be a good start. > - Some discussion around whether we should limit to one project per > stack? Venky: Prefers not to > - Chris: How do decisions on new projects get made? My understanding is that some new projects/layers can be added under the dpdk.org umbrella. So different implementations of a DPDK layer will be hosted in different dpdk.org git trees. But some implementations cannot move there, e.g. ovs-dpdk. What about https://01.org/spdk? http://www.seastar-project.org? https://github.com/rumpkernel/drv-netif-dpdk? https://01.org/intel-data-plane-performance-demonstrators? > We finished the discussion with a brief conversation on whether we > should maintain certain branches for a long time. 1.8.0, 2.0.0, 2.1.0, the last digit can be used for stable branches. > Bruce: Adds a lot of overhead > Venky: Can do point releases on some branches > Stephen: Prepared to "volunteer" someone from Brocade, because they need > to maintain an older release anyway. You just need to send me a SSH key and the version to maintain in order to have a dedicated git tree. Then the fixes should be preferably backported from the main tree. Thanks everybody for the useful discussions.