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 4B385A04EF; Mon, 25 May 2020 18:02:15 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 248E41D92F; Mon, 25 May 2020 18:02:14 +0200 (CEST) Received: from mail-il1-f195.google.com (mail-il1-f195.google.com [209.85.166.195]) by dpdk.org (Postfix) with ESMTP id 5CBD31D91B; Mon, 25 May 2020 18:02:12 +0200 (CEST) Received: by mail-il1-f195.google.com with SMTP id 18so17724758iln.9; Mon, 25 May 2020 09:02:12 -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=OaZiwG3lcSs5KCfu35n2TbeIF9wFvGoUiLrbxp1nwU8=; b=WnUHVOjUJFKROdtFayEWCJFafnxAXdaoq+udz3Pst81/CPChD7VaZmpTABq9vc5U2I RK0wvJcC1lidjwFtK9YHuMYvx8kwhoGCuhStqP/4xPd998xaliOgPujFSLTj0BTwTi+F k+E/amSCRt3GdAsyozTJDyKRtoCvoIk9ibm0zHsIuGuXvPS7C6jjuKlNBMA4caUy2NRm OKSsVuC08d2Wa5eLLkWg5/y1LPt6h5dc7xrzdQyNu9ORmHiogPLTlCDjADxxHMojtkrz bySvU5tKTQztk6RvJ9VfLMmQfWerM+nV4jQ7poNspLH7WLlfy9r1sshYJa+UjhtGCwK+ lE7A== 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=OaZiwG3lcSs5KCfu35n2TbeIF9wFvGoUiLrbxp1nwU8=; b=cvhshXIAq4oxDo1+jUrwAO3P64cJ4L/VUC+TBX+2Nb5bC7Gv41mfhbJjeoeWqSERdX I4cBLm40V0zU/x4g2ZCT93pAmUx3+jUB8ObdfN8fACWxxSebIlIamJBP/T7TIqfGlkh3 56JPauXQIvcE118h1NfCsx7pK1Y7fIDWmfj7St1rp1esVr2MdRmRvZoO5H/kjxMHSofp VnIXpAgqm6h/6zEeH+JRecaT6xyXoc2G7enGorYWw2KunUiEX06YApvM/hiSWm3Hdsul 3YoWASu1Ds8IemJMV4MoxzYnp/zHesDYoC4mUUfMwE8kvujzxCP8lZYRH+R+hg8X56n7 YLcw== X-Gm-Message-State: AOAM533gIfMgh0HsxeMIYnUYZHYEYlI3mjI1ecLKbVOVzP7NgSYKcXRQ o63mbg/qP/yLM9c5oPuQ+BsYSMphHmXWQWpAWzo= X-Google-Smtp-Source: ABdhPJxrXiXv8Bq5M1zycNYcIbJ46iSIZgAwcBe4tfRhSCcUWxiRg0ZHJy3dUn+M7BcNE8bmMuxv7RxCAysjBh6yfE8= X-Received: by 2002:a92:8c4a:: with SMTP id o71mr26133962ild.130.1590422531456; Mon, 25 May 2020 09:02:11 -0700 (PDT) MIME-Version: 1.0 References: <98CBD80474FA8B44BF855DF32C47DC35C60FEA@smartserver.smartshare.dk> <2346940.LZvDnYUUCF@thomas> <354a7cf6-788b-debf-1939-541410a1099b@intel.com> <3551245.iDPhyKTcbK@thomas> <04ce22d8-1e23-5c75-5947-44c8bca040d5@redhat.com> In-Reply-To: <04ce22d8-1e23-5c75-5947-44c8bca040d5@redhat.com> From: Jerin Jacob Date: Mon, 25 May 2020 21:31:55 +0530 Message-ID: To: Maxime Coquelin Cc: Thomas Monjalon , =?UTF-8?Q?Morten_Br=C3=B8rup?= , "Burakov, Anatoly" , 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 DPDK contribution 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 Mon, May 25, 2020 at 9:22 PM Maxime Coquelin wrote: > > > > On 5/25/20 5:35 PM, Jerin Jacob wrote: > > On Mon, May 25, 2020 at 8:52 PM Thomas Monjalon w= rote: > >> > >> 25/05/2020 16:28, Burakov, Anatoly: > >>> On 25-May-20 1:53 PM, Thomas Monjalon wrote: > >>>> 25/05/2020 13:58, Jerin Jacob: > >>>>> 25/05/2020 11:34, Morten Br=C3=B8rup: > >>>>>> sending patches over an > >>>>>> email as opposed to a well-integrated web interface workflow is so= alien > >>>>>> to most people that it definitely does discourage new contribution= s. > >>>>>> > >>>>>> I understand the advantages of mailing lists (vendor independence, > >>>>>> universal compatibility, etc.), but after doing reviews in Github/= Gitlab > >>>>>> for a while (we use those internally), going through DPDK mailing = list > >>>>>> and reviewing code over email fills me with existential dread, as = the > >>>>>> process feels so manual and 19th century to me. > >>>>> > >>>>> Agree. I had a difference in opinion when I was not using those too= ls. > >>>>> My perspective changed after using Github and Gerrit etc. > >>>>> > >>>>> Github pull request and integrated public CI(Travis, Shippable , > >>>>> codecov) makes collaboration easy. > >>>>> Currently, in patchwork, we can not assign a patch other than the s= et > >>>>> of maintainers. > >>>>> I think, it would help the review process if the more fine-grained > >>>>> owner will be responsible for specific > >>>>> patch set. > >>>> > >>>> The more fine-grain is achieved with Cc in mail. > >>>> But I understand not everybody knows/wants/can configure correctly > >>>> an email client. Emails are not easy for everybody, I agree. > >>>> > >>>> I use GitHub as well, and I really prefer the clarity of the mail th= reads. > >>>> GitHub reviews tend to be line-focused, messy and not discussion-fri= endly. > >>>> I think contribution quality would be worst if using GitHub. > >>> > >>> I have more experience with Gitlab than Github, but i really don't se= e > >>> it that way. > >>> > >>> For one, reviewing in Gitlab makes it easier to see context in which > >>> changes appear. I mean, obviously, you can download the patch, apply = it, > >>> and then do whatever you want with it in your editor/IDE, but it's ju= st > >>> so much faster to do it right in the browser. Reviewing things with > >>> proper syntax highlighting and side-by-side diff with an option to se= e > >>> more context really makes a huge difference and is that much faster. > >> > >> OK > >> > >> > >>> I would also vehemently disagree with the "clarity" argument. There i= s > >>> enforced minimum standard of clarity of discussion in a tool such as > >>> Gitlab. I'm sure you noticed that some people top-post, some > >>> bottom-post. Some will remove extraneous lines of patches while some > >>> will leave on comment in a 10K line patch and leave the rest as is, i= n > >>> quotes. Some people do weird quoting where they don't actually quote = but > >>> just copy text verbatim, making it hard to determine where the quote > >>> starts. If the thread is long enough, you'd see the same text quoted > >>> over and over and over. All of that is not a problem within a single > >>> patch email, but it adds up to lots of wasted time on all sides. > >> > >> Yes > >> > >> My concern about clarity is the history of the discussion. > >> When we post a new versions in GitHub, it's very hard to keep track > >> of the history. > >> As a maintainer, I need to see the history to understand what happened= , > >> what we are waiting for, and what should be merged. > > > > IMO, The complete history is available per pull request URL. > > I think, Github also email notification mechanism those to prefer to se= e > > comments in the email too. > > > > In addition to that, Bugzilla, patchwork, CI stuff all integrated into > > one place. > > I am quite impressed with vscode community collaboration. > > https://github.com/Microsoft/vscode/pulls > > Out of curiosity, just checked the git history and I'm not that > impressed. For example last commit on the master branch: > > https://github.com/microsoft/vscode/commit/2a4cecf3f2f72346d06990feeb7446= b3915d6148 > > Commit title: " Fix #98530 " > Commit message empty, no explanation on what the patch is doing. Yes. The merging rules, how much review is required, sanity test to per check-in will be specific to the project requirements. I can see zephyr RTOS project(I am following this project) will be more close to the coding standard and other requirements. https://github.com/zephyrproject-rtos/zephyr/pulls > > Then, let's check the the issue it is pointed to: > https://github.com/microsoft/vscode/issues/98530 > > Issue is created 15 minutes before the patch is being merged. All that > done by the same contributor, without any review. >