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 D08EAA0512; Wed, 3 Jun 2020 15:56:35 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B974F1D446; Wed, 3 Jun 2020 15:56:34 +0200 (CEST) Received: from mail-io1-f65.google.com (mail-io1-f65.google.com [209.85.166.65]) by dpdk.org (Postfix) with ESMTP id CACEF1D152; Wed, 3 Jun 2020 15:56:32 +0200 (CEST) Received: by mail-io1-f65.google.com with SMTP id r2so2329414ioo.4; Wed, 03 Jun 2020 06:56:32 -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=8jnWz67QiAwFWetRsENSF7Us7Y0CjvDSrTH8o9KPN8o=; b=ZftjVCpkZODKWpwe5MVXu5Kh9t1om/UVEMGYxLdYjv3f6SEJSftHMlkWQHhggMDQ3O lMM7quyuQ0SkuLCyoY67pmfDeHNAelSPSkXhTZHyswpIsqd/RLr3EAX/YM4vomN66/ja xOBW4zWHCeAKO0DlRUDVhw7jDRH6fB8p+SK0Kwx9dlQ/LOKjkvH6tE8OI4aTkNyxke5D nh1OM9n65edWRvWocGK79rCffcsOrg6n1yzzd6o5YADAhN5dSEktRuh5R0HQLUYQS9+A oZjgeZa+8iceeOWmxYM/KvJRGIQCOYWulUtxhWy35M7N5ZMBqY2QTJX7zFlQgljSyt6R fV8w== 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=8jnWz67QiAwFWetRsENSF7Us7Y0CjvDSrTH8o9KPN8o=; b=QbXfd1dMecx3k7v7Ryl/cZ4vHJG3Z4Al975Edg3GilVGnNB7BNnRVcfYGodJDJwG33 cUwW/iZLwmGjIgxjng5CIrG9XWip2et2sJCa5yg3OxsqI5+NAgQspsfCTpscR9F8DRcP 7n/GfrWZ/SjiPYZneTP9s7sgjED6MOjeSD13RGttn4HqgFpk0T9bvGW14SX1YI0F6b8l kUmTykfvF79CKHH2IbJhF1myugw2GN9k1AgXXctYKDsltFM1EAAd8FyU7J68MiBMw77b iVW6cHgnJhy1bbvWdwjhgEBdEhWCgEJe03SXoY4AqGKA7J4O8xQ6/IEA1cjzM6QoaCc/ rapA== X-Gm-Message-State: AOAM530raI91GepcdHr4ci7QWNYvmf1vn7vl9bIt1NSnftzy9fNK3QQ/ 67v1H6qm4F0eCRIa7ZCUUgvRxhZixDKEM2rL1qY= X-Google-Smtp-Source: ABdhPJwtkeYjZr5WTo6UhWAlJ/Ejhwn308qYHKf+a9pUiapkH9Qo9izhsyrcTYOxgbpPZ0XaMqBG5Uvo1w5jmJETWkI= X-Received: by 2002:a05:6602:2dca:: with SMTP id l10mr3601815iow.163.1591192591983; Wed, 03 Jun 2020 06:56:31 -0700 (PDT) MIME-Version: 1.0 References: <20200527100833.tuy5q66mfqfynxlf@u256.net> <4c84b979-5da3-1e34-fa85-a91c0fca7622@intel.com> In-Reply-To: <4c84b979-5da3-1e34-fa85-a91c0fca7622@intel.com> From: Jerin Jacob Date: Wed, 3 Jun 2020 19:26:15 +0530 Message-ID: To: Ferruh Yigit Cc: =?UTF-8?Q?Ga=C3=ABtan_Rivet?= , Jerin Kollanukkaran , dpdk-dev , Thomas Monjalon , "david.marchand@redhat.com" , Maxime Coquelin , "cristian.dumitrescu@intel.com" , "akhil.goyal@nxp.com" , "rasland@mellanox.com" , "xiaolong.ye@intel.com" , "ajit.khaparde@broadcom.com" , "arybchenko@solarflare.com" , "Burakov, Anatoly" , "techboard@dpdk.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, Jun 3, 2020 at 6:39 PM Ferruh Yigit wrote: > > On 6/2/2020 5:23 PM, Jerin Jacob wrote: > > On Tue, Jun 2, 2020 at 8:27 PM Ferruh Yigit wr= ote: > >> > >> On 6/2/2020 1:27 PM, Jerin Jacob wrote: > >>> On Wed, May 27, 2020 at 3:38 PM Ga=C3=ABtan Rivet wr= ote: > >>>> > >>>> On 27/05/20 09:28 +0000, 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 DP= DK workflow. > >>>>> > >>>>> Current scheme: > >>>>> - When we submit a patch to ml, someone(Tree maintainer[3]) needs t= o manually > >>>>> delegate the patch to Tree maintainer in patchwork. > >>>>> - Tree maintainer is not responsible for the review of the patch bu= t 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 to= ols 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 s= urprise on > >>>>> review responsibility and improve review traceability. > >>>>> > >>>>> Implementation of the proposed scheme: > >>>>> GitHub provides a bot for CODEOWNERS integration, Similar alternati= ve 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 intr= oducing 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/ > >>>>> > >>>> > >>>> Hi, > >>>> > >>>> +1 from me. People would be able to list current assigned tasks thro= ugh > >>>> pwclient. It would help reviews IMO. > >>> > >>> So far no objection to this proposal. Any other thoughts from anyone? > >>> especially from the code maintainers. > >>> > >>> Thomas, Any input as patchwork maintainer. This would boil down to th= e > >>> following change in patchwork. > >>> > >>> 1) Add code maintainers are maintainers in patchwork. > >>> 2) Enable existing auto delegation[1] feature of Patchwork > >>> [1] > >>> a) https://patchwork.readthedocs.io/en/latest/usage/delegation/ > >>> b) https://patchwork.readthedocs.io/en/latest/usage/headers/ > >>> > >>> The suggested process is: > >>> # When a patch gets submitted to ml, patchwork finds the code owner > >>> based on the MAINTAINER file using the auto delegation feature. > >>> # The code maintainer will be responsible for the "review" of that > >>> patch and patch will be delegate will code owner using auto delegatio= n > >>> feature. > >>> # If multiple code maintainers operate on the same patch, "each code > >>> maintainer" can assign to "other code maintainer" once he is done wit= h > >>> the review. > >>> # The existing review process will be followed as is, just that we ar= e > >>> adding code maintainer have primary review responsibility for the > >>> patch and expressing in the patchwork. > >>> # Based on the Ack's received and/or when code owner is happy with > >>> changes, he/she can change the state to "Awaiting upstream" and > >>> assign to respective > >>> tree maintainer. > >>> # Finally, Tree maintainer will merge the patch to respective tree an= d > >>> make the state as "Accepted" > >>> > >> > >> +1 from me, this can help maintainers to figure out patches waiting fo= r their > >> review. > >> > >> Did you have a chance to test auto delegation, will it work for us? > > > > I think, it can be done in two ways > > > > a) https://patchwork.readthedocs.io/en/latest/usage/delegation/ > > b) https://patchwork.readthedocs.io/en/latest/usage/headers/ > > > > Option (a) need patchwork admin access and no dependency on email > > client nor separate step[1]. I think, only Thomas only has access to > > that. > > I tested the option (b). It is not working, it is not straight forward > > as we need to specific header to email[1] > > Based on my debugging, Even though when I did "add-header", it is not > > showing up on received email. Somewhere it is getting removed[2] > > > > [1] > > git send-email --to dev@dpdk.org --add-header=3D"X-Patchwork-Delegate: > > ferruh.yigit@intel.com" > > 0001-test-test-patch-for-checking-patchwork-auto-delegati.patch > > [2] > > http://patches.dpdk.org/patch/70749/ > > > > I did able add the header to the email, it worked if you gave the '--add-= header' > to "git format-patch" and send that patch, instead of using "git send-ema= il" > directly: > http://inbox.dpdk.org/dev/20200603130005.3709131-1-ferruh.yigit@intel.com= /raw > X-Patchwork-Delegate: ferruh.yigit@intel.com > > But it didn't show up in the patchwork, not sure why. > > Also this way is not a good solution, instead of the sender of the patch > delegating, this should be automated in the server side. I think option a= ) above > is the way to go. Yes. option a) is always better. Patchwork admin can only test option (a). Looking forward for Thomas's cycles to check if he agee with this process. Another option could be to have wrapper script for git format-patch to to add -add-header using ./devtools/get-maintainer.sh script so that it is completely automated if option (a) not viable.