From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 5233EA04A4; Tue, 26 May 2020 12:34:04 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BD9EB1DA1D; Tue, 26 May 2020 12:34:03 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id EA08B1DA1B; Tue, 26 May 2020 12:34:01 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 29C675C008E; Tue, 26 May 2020 06:34:01 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 26 May 2020 06:34:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= bKazSlbbIYAm4feb8Bq2g92EVC4t08s7tWLpKTlIWXU=; b=ODfNAfxU0O+RrYDV nSeB4TQQOqBwCZwBVMpCl9Q/HqH3NIOE+S1mfFOu9r7otyRcpurtI+C/EZutjZtN ymNvLkFL9f332nJuG+dcu688g0FZDDttWZa5Y/R/89lds1WqwybhqOXNjhkvHyzx ycbD8T2XudLz53P2aBM5zdT+x4b6v6QHhVNNs58rgJEd6ojeIvTLmsBip0zl0JmX v0T54vb0gIYyBVapjNpY+QuuYgZ215/0H8QhKVW3wLyR3BvDBGJoq8n9EF7qTw0E 6yrhgsKUN1ZolMmz6tkpEH35gKz+eO0AKMUFQQYLdqvysTfQ0k5NHqXvH35pZPRD WF1BNw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=bKazSlbbIYAm4feb8Bq2g92EVC4t08s7tWLpKTlIW XU=; b=qIYQF6svtXXvPiG0SNSz8RR3SVQx7rY/7tSkPDM2tFRwSaHAy+CXVkF3b 4bOShudYI7mmgd8Qy8Ju9RpwoLP88i2HoT5WngRcryD8XmRh9mIFf2sWuMXiQc5Q MjiDEZXdRqJeNAN3ivJ3GLiqzwIpJNIeG+O29cyL9fQ2es2SSZEyzu8r6KFeka9a EfqRwtVoqRMI0qRu5l4sGkpmOTOtGq2Lm8B5jIYdqU/PNcPuWNRUKkOp/bvpMc7h LyiE5YSoREv3BO2DhUmC39jS0b1Ij90fl3XJs5k3X5COr4T/5t7CEWi1cuCZT6X3 TJhpYr3Qb/Oy3GeWdZB0Z/ixTHsQg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddvvddgvdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtqhertddttddunecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnheptedtvdevueekjeelfeffuddvhefgvdehkeegheefhfetjefgledv ffejledtgfdtnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpughpughkrdhorhhgne cukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id A108B328005E; Tue, 26 May 2020 06:33:59 -0400 (EDT) From: Thomas Monjalon To: "Burakov, Anatoly" , Jerin Jacob Cc: Morten =?ISO-8859-1?Q?Br=F8rup?= , Maxime Coquelin , dpdk-dev , techboard@dpdk.org, "Jim St. Leger" Date: Tue, 26 May 2020 12:33:58 +0200 Message-ID: <1664892.001bYUvlCK@thomas> In-Reply-To: References: <98CBD80474FA8B44BF855DF32C47DC35C60FEA@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Subject: Re: [dpdk-dev] [dpdk-techboard] Consider improving the DPDKcontribution processes X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 26/05/2020 12:16, Jerin Jacob: > Burakov, Anatoly wrote: > > On 25-May-20 7:44 PM, Morten Br=F8rup wrote: > > > From: Thomas Monjalon > > >> About the barrier for entry, maybe it is not obvious because I don't > > >> communicate a lot about it, but please be aware that I (and other > > >> maintainers I think) are doing a lot of changes in newcomer patches > > >> to avoid asking them knowing the whole process from the beginning. > > >> Then frequent contributors get educated on the way. > > > > > > Great! I wish that every developer would think and behave this way. > > > > Part of the problem is, there are two different maintainers here: > > maintainers like myself, who maintain a certain area of the code, and > > maintainers like Thomas, who has *commit rights* and maintains the > > entire tree. Let's call these roles "component maintainer" and "tree maintainer". > Yes. I had a similar thought when I said about the "fine-grained" > maintainership/ownership. > The patchwork does not reflect the fine-grained owner of this patch serie= s. Indeed, patchwork is about patch integration status. The delegated person is the one responsible for merge, not review. > IMO, patch review will speed up or improve if we give the > responsibility of the patch to > specific maintainer based on the MAINTAINERS file. I partially disagree about being strict on review responsibility. Reviews can and should be done by anyone in the community. This is how we scale: avoid bottlenecks. Reminder: multiple reviewers are better, and should be the standard. The component maintainer responsibility is doing some reviews of course, but the main responsibility is to make sure reviews are done. > Github picks up the default owner as CODEOWNERS(The PRIMARY one > responsible for the file or section of the code) > https://github.com/zephyrproject-rtos/zephyr/blob/master/CODEOWNERS. The git-send-email option --cc-cmd devtools/get-maintainer.sh does a good job at finding code owners. > The policy for merge permission( Can CODEOWNERS merge the patch) will > be specific to the project. > IMO, This scheme would enable CODEOWNERS are more responsible for the > code review and > we have need system where query what is pending the CODEOWERS. > This http://patches.dpdk.org/project/dpdk/ list does not depict the > CODEOWERS in DPDK. Not sure I understood your proposal. You would like one more column in patchwork which is automatically filled with code owners? > > And therein lies the problem: Thomas (David, etc.) doesn't look at every > > area of the code, he relies on us to do it. However, *he* is doing the > > committing, and fixing up patches, etc. - so, i can't really say things > > like, "hey, your indentation's wrong here, but Thomas will fix it on > > apply" because that's me pushing more work onto Thomas, something i > > don't think i have the moral right to do :) You can send a new version of the patch with the details fixed, publicly readable, reviewable, and ready to be pushed. > > So, while Thomas is free to "fix on apply" at his own desire, i don't > > think we have to make this a habit. Yes, it should be more or less an exception. Bottom line, it is important to be transparent and predictable, while keeping some flexibility.