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 3024DA0093; Wed, 27 May 2020 13:28:02 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1C2AE1D651; Wed, 27 May 2020 13:28:01 +0200 (CEST) Received: from mail-io1-f68.google.com (mail-io1-f68.google.com [209.85.166.68]) by dpdk.org (Postfix) with ESMTP id 4FA4F1D614; Wed, 27 May 2020 13:28:00 +0200 (CEST) Received: by mail-io1-f68.google.com with SMTP id f3so25520516ioj.1; Wed, 27 May 2020 04:28:00 -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; bh=432qIOfcCveSEv31Z9zUFyVvb0e4crtW3JLYvPvc3tM=; b=KLUDUsE0xdC2JWy3rehj4/3u0sYeTgj0oppHmKZtyl/epu+h6EdK0sZsBIg1DjLMMd cHwbxOk5XD+GI9xGdFj0OVHqm4N1zYE3T1A2ItjVF4/Yp/25sHD/2Z690sis/Oq4JEzr lpjj37ISA/0YhFcQTcd70TGk3qE2FXS59SzzxBarBjreIh468oTLeI4S8I8WXZEET9lI oSzN57EG4zQgRvovoZkg/8GCo1psdQq3DBg/SQcmjUixk73Wk6Ff2CR8iYLAGkXlj2Lg JZDI2k79mJ18ZjxyMmcwekamQj5xcK2Vpq+oDHbL3aWejhp75u/D2BhgMb8epiChGMBA PHZg== 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; bh=432qIOfcCveSEv31Z9zUFyVvb0e4crtW3JLYvPvc3tM=; b=EuihWZ2VeQarjvd7pV8o18lOlYsALy1hWiw5+Ke8/RYwfx60YGagmPSSjSVKR2lIlp WW3RUcj+3PAfIj9ppM8mqKa++pAkPyYaERDBVfFMmJYENcEDsQyh8U4zgdAMllpONNfb A1nMR4ZA+pvzvqfKNjCX0mOdfAqKvrF7yrOiy0Fz4hFTjnryWLGbxOxSE5J/JUXgsZal HPfvCCmdaQ9TkJunAjvY0x43PBr4RQN3BniEeJluyw1GzycfTn3vW5deVKAkm4iHqFT0 3w1Aw1WM+s4ePQ6GahVsfXcTS9/FO5NunGlJ7eRwa9bF1TL/Ln2iPpZy7RewxEzrQbms MiSQ== X-Gm-Message-State: AOAM5330V419oyEeIr5fIupo2RZHUIj3WdX2KEsnOag+MhtLuFYHHA5V 6yK3cbKKjiDT3THsKMktNaiH908DF+E2qK+MeRo= X-Google-Smtp-Source: ABdhPJx7wzB+swkGzo5CqHpmQmBAKOXiltV3exYaohAeQ5e+Y55pe/Sf6KSbokNR7CgDggAzU2ECNRvZELFFO/aTHqw= X-Received: by 2002:a02:7113:: with SMTP id n19mr4931656jac.113.1590578879349; Wed, 27 May 2020 04:27:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jerin Jacob Date: Wed, 27 May 2020 16:57:43 +0530 Message-ID: To: "Burakov, Anatoly" Cc: Jerin Kollanukkaran , dpdk-dev , Thomas Monjalon , "david.marchand@redhat.com" , "Yigit, Ferruh" , Maxime Coquelin , "cristian.dumitrescu@intel.com" , "akhil.goyal@nxp.com" , "rasland@mellanox.com" , "xiaolong.ye@intel.com" , "ajit.khaparde@broadcom.com" , "arybchenko@solarflare.com" , "techboard@dpdk.org" Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] Suggestion to improve the code review 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 Wed, May 27, 2020 at 3:29 PM Burakov, Anatoly wrote: > > On 27-May-20 10:28 AM, Jerin Kollanukkaran wrote: > > I think, original discussion[1] on this topic got lost in GitHub vs current workflow. > > > > > > I would like to propose GitHub "CODEOWNERS"[2] _LIKE_ scheme for DPDK workflow. > > > > Current scheme: > > - When we submit a patch to ml, someone(Tree maintainer[3]) needs to manually > > delegate the patch to Tree maintainer in patchwork. > > - Tree maintainer is not responsible for the review of the patch but only responsible > > for merging _after_ the review. That brings the obvious question on review responsibility. > > > > > > Proposed scheme: > > - In order to improve review ownership, IMO, it is better the CI tools delegate > > the patch to the actual maintainer(who is responsible for specific code in MAINTAINERS file) > > - I believe, it provides a sense of ownership, avoids last-minute surprise on > > review responsibility and improve review traceability. > > > > Implementation of the proposed scheme: > > GitHub provides a bot for CODEOWNERS integration, Similar alternative is possible with > > patchwork with "auto delegation scheme" using the flowing methods: > > > > a) https://patchwork.readthedocs.io/en/latest/usage/delegation/ > > b) https://patchwork.readthedocs.io/en/latest/usage/headers/ > > > > I think, option (a) would be relatively easy to change without introducing the new tools. > > > > Thoughts? > > > > [1] > > http://mails.dpdk.org/archives/dev/2020-May/168740.html > > [2] > > https://github.com/zephyrproject-rtos/zephyr/blob/master/CODEOWNERS > > [3] > > https://patchwork.dpdk.org/project/dpdk/ > > > > The "which patches should i review first" button is a huge +1000 from > me, as this has been a big issue i've had with current workflow for a > long time. Thomas has mentioned "Cc:" as a "fine grained" system to > assign patches, but the truth is, CC is not a good way of doing it > because i get CC'd in all kinds of stuff, and the important patches get > lost. > > That said, i don't think it's that easy, because more often than not, > patches touch a lot of different areas, so a one line change in meson, a > test and a line in EAL gets half of DPDK maintainers CC'd into the > patch. I wonder if there is a mechanism for some kind of "threshold" for > assigning people to the patch - i.e. if a one-liner is half of the > changes in the patch, then maintainer gets CC'd, but if a one-liner is > just one of a thousand other unrelated lines, then perhaps there's no > need to CC the maintainer... or something along those lines :) there's a > machine learning project in here somewhere :D Github has a scheme on the review on Round-robin fashion if it touching in the multiple areas. it will be too much for patchwork. At least in patchwork, if you are done with the review or you can assign to another code maintainer manually. https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/managing-code-review-assignment-for-your-team > > -- > Thanks, > Anatoly