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 49581A04EF; Mon, 25 May 2020 17:43:57 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 17E391D647; Mon, 25 May 2020 17:43:57 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 830A71C07E; Mon, 25 May 2020 17:43:55 +0200 (CEST) IronPort-SDR: 4Xteu9KScVQBIELB7jize8reAyc6QBJMi+9GlLA5zxOF2mCVHabYlYK+Q9yE4Qx5HCknJ7Q3Wu ygxnPgXeDbZA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 May 2020 08:43:54 -0700 IronPort-SDR: 5OwqjmTGS9dTwb5pBXDlbBgjqWffScjTnbj37CAjLVaiUu+zfr4bWEjQ3DoZNJJLxT59UspsSM klJTqW4fHpUA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,433,1583222400"; d="scan'208";a="468081775" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.212.230.177]) ([10.212.230.177]) by fmsmga006.fm.intel.com with ESMTP; 25 May 2020 08:43:52 -0700 To: Thomas Monjalon , =?UTF-8?Q?Morten_Br=c3=b8rup?= , Jerin Jacob Cc: dev@dpdk.org, techboard@dpdk.org, "Jim St. Leger" References: <98CBD80474FA8B44BF855DF32C47DC35C60FEA@smartserver.smartshare.dk> <2346940.LZvDnYUUCF@thomas> <354a7cf6-788b-debf-1939-541410a1099b@intel.com> <3551245.iDPhyKTcbK@thomas> From: "Burakov, Anatoly" Message-ID: <0a15cc11-6edd-d543-fd6c-7eb35948e068@intel.com> Date: Mon, 25 May 2020 16:43:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <3551245.iDPhyKTcbK@thomas> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] 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 25-May-20 4:22 PM, Thomas Monjalon wrote: > 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ørup: >>>>> 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 contributions. >>>>> >>>>> 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 tools. >>>> 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 set >>>> 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 threads. >>> GitHub reviews tend to be line-focused, messy and not discussion-friendly. >>> I think contribution quality would be worst if using GitHub. >> >> I have more experience with Gitlab than Github, but i really don't see >> 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 just >> 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 see >> more context really makes a huge difference and is that much faster. > > OK > > >> I would also vehemently disagree with the "clarity" argument. There is >> 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, in >> 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. And AFAIK you do have access to discussion for older versions of the PR, do you not? Again, i didn't do in-depth reviews with multiple revisions and threads on Github, but assuming Gitlab works similarly, we do have access to that. > > >> And all of the above will not be a problem with a tool like >> Gitlab/Github. There are "general" comments that can be used for general >> discussion, and there are line-specific comments that can be used to >> discuss certain sections of the patch. I've done this many times in many >> reviews, and it works very well. Now, granted, I've never maintained an >> entire repository like DPDK, so you may have a different perspective, >> but i really don't see how long email chains have "clarity" that a >> discussion thread with proper quoting, links to code, markdown syntax, >> etc. doesn't. > > You don't have discussion threading in GitHub. Is there? Threading is implicit when you are commenting under a line of code. Of course this rests on an assumption that you wouldn't use a random comment thread to bring up things from another thread, but nothing is perfect :) > > >> (for the record, i don't consider Gerrit to be a good tool because it >> enforces a particular git workflow, one that is not at all compatible >> with how our community works. GitLab, on the other hand, "just works" - >> i'm assuming GitHub is very similar) >> >>> >>> There is a mailing list discussing workflow tooling: >>> https://lore.kernel.org/workflows/ > > > -- Thanks, Anatoly