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 11271A04A4; Tue, 26 May 2020 12:54:00 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DAA5D1D6F1; Tue, 26 May 2020 12:53:59 +0200 (CEST) Received: from mail-il1-f193.google.com (mail-il1-f193.google.com [209.85.166.193]) by dpdk.org (Postfix) with ESMTP id E8DAE1D63E; Tue, 26 May 2020 12:53:57 +0200 (CEST) Received: by mail-il1-f193.google.com with SMTP id 18so19902526iln.9; Tue, 26 May 2020 03:53:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=WexnN4MQ/o8IjtlcTv4Yp881QpyL+8E7N4xuMYk2erg=; b=T9sMWA850beEf1nAuCAIGYSP9RX4wR5HtEdmnEg9F55m8X03DvZSw68Vmn+NzqRigD TzFjfHTtcT/G1MAYws+cWV8+PRsQWzuGGmF02FqfjgAJUnyn6Yo9HLR6HtLorWmzxtiS ENHXXMZZgP5f+d68BLL9S3yRhsfJgFa59/dx76ZWg7Up+yFY0flPW++ZpOu+iuDRMhl7 lQOP37tuXUQbUIKNGd9QQmQuhKyLoDMMYJGat4HoTi+NEOSMDVLOrzJ615+axwobYLDa LKCAmE6wcC2VFG+VgF0M6VO7bA2YHgLfx7CuCKQrGiR7WIVGB6kowv8Z5s3FNuNgJz6u GLnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=WexnN4MQ/o8IjtlcTv4Yp881QpyL+8E7N4xuMYk2erg=; b=D49wlaNAHwY54fRXZcyGcSpENAIvbiaJTl/3XlMFjfxIJTb+0+TSH0KNp1ahQN7+SX JbGLFuxxW2Li8TMXTNgrZ7F5AOjzs+t4U0PrP4WgMw7u1gQjCaPdCwFlzFQu5isvodQQ yVGq2Zn4mN2lkZQJHQFik/qyIvqVTtqCXt3Q3YZcKheGCH0dUOtVZlwy+PKSbjhFEfPr 4t9IvekGFms1IA6qNNMYxvj7hfvFmqrnSzt+hULOhp0OoL2kxitVpbCfHHAiAiIA7pN6 Ovqqr90SW4anO2mQoIun+5Kuj1/SeLuqtjUc+JUIZ2DzVV18t2JqrKlA/zjqTp6oi9/Y TKfQ== X-Gm-Message-State: AOAM531cjbL92aPMxGl9724tQ0e59CR0wmjN1ysViLXWC3eDg0l60cJA Qy6ieTpqViuBqv4WeQTgGgtzbg91HCMb3ehs5scBQDSa0GQ= X-Google-Smtp-Source: ABdhPJxyTYYxU1htflTdWoMV5XcDbbsH3dzAtkGrLdGFl2t4E1SXkCmZlJjpFQOjnseXzasrQMWVnT5msX4D960JNSg= X-Received: by 2002:a92:d188:: with SMTP id z8mr459629ilz.60.1590490437191; Tue, 26 May 2020 03:53:57 -0700 (PDT) MIME-Version: 1.0 References: <98CBD80474FA8B44BF855DF32C47DC35C60FEA@smartserver.smartshare.dk> <1664892.001bYUvlCK@thomas> In-Reply-To: <1664892.001bYUvlCK@thomas> From: Jerin Jacob Date: Tue, 26 May 2020 16:23:41 +0530 Message-ID: To: Thomas Monjalon Cc: "Burakov, Anatoly" , =?UTF-8?Q?Morten_Br=C3=B8rup?= , Maxime Coquelin , dpdk-dev , techboard@dpdk.org, "Jim St. Leger" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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" On Tue, May 26, 2020 at 4:04 PM Thomas Monjalon wrote= : > > 26/05/2020 12:16, Jerin Jacob: > > Burakov, Anatoly wrote: > > > On 25-May-20 7:44 PM, Morten Br=C3=B8rup 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 patche= s > > > >> 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 ser= ies. > > Indeed, patchwork is about patch integration status. > The delegated person is the one responsible for merge, not review. Yes. That's the problem. Merge will happen after the review. Who is the owner of the review? It should be "component maintainer" and it needs to track somewhere to see the status and know the trend for release. That make more transparent and know the fate on the patch on early stage. > > > 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. Yes. No disagreement on that. Anyone free to review. None of the above prop= osed the scheme is stopping it. > > 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? Yes and the patch's primary _review_ responsibly will be with code owners and "tree maintainer" apply the patch in fixed time when gets ack from primary code owner and if there is no comment from "tree maintainers". > > > > > And therein lies the problem: Thomas (David, etc.) doesn't look at ev= ery > > > area of the code, he relies on us to do it. However, *he* is doing th= e > > > committing, and fixing up patches, etc. - so, i can't really say thin= gs > > > 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. I agree. > >