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 ADF43A04EF; Mon, 25 May 2020 19:32:13 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D99811D977; Mon, 25 May 2020 19:32:12 +0200 (CEST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by dpdk.org (Postfix) with ESMTP id E4B881D976; Mon, 25 May 2020 19:32:11 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 83A6A4FE; Mon, 25 May 2020 13:32:08 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Mon, 25 May 2020 13:32:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= 4MhpCsAlcNxBDC5JmKkUslXQaS90FXKigl7CA1jiap0=; b=d1PknkXhKheaGkIB GYnEgVh0kyMd5we91l9ajMtzwedS0QQR2zdtroxuhzuGqx/46SfMW0GVzUOEZ0i7 bih8UD/Tboxyk+DjQpXTi82atVSzWHsO65MSa9Jtwen9YAygrwAU67dD0pCEBWb6 cJLO+lVJbqtY3hvuvSJPgDygn7yRUrnkXk16DS68iEga207TnOzxi/7jQSiPI38e muq85zEpfsGpNB9Hbf/28n2oHXGT/KfgEy1QDHvZBRO+sEA9MfFE5/7PD58PAmnf sYQoMGc/hWI/7BebA8zZybTgKw9/lzWEyCI6/OnyEd82GK/VJOw6ksGV387D5ZMZ 1MqbQA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=4MhpCsAlcNxBDC5JmKkUslXQaS90FXKigl7CA1jia p0=; b=XJdo7Kwa1RqNozw+Dyrrpy3UzmNsqz7zu/S0T5fw5JaqsPxSvPVA42y7z br88xNtaPKCm1zknkqcm+/UioC3R3MAx8NIrD0C46lnQl0cYk/7BZ3mmPnkFt7lt okAEmM7xwfI6KlYQPpHp9YrjajgCUCYd9MJSUMXoAYIAkF1uRAxITLkdK+L4KurM z7AD9JMeI88su0IYNkEPCpZN8a0o/jZKSM61NMF9/fx8+NyWBVZzvBFNPrbKHiPd qr8yn6xBjKpWcxa8poxH+rs9bVhPVeUkV1a/ecJZ961+GPfb80gG137fmf3K1ixo ZRYAxcHCNpVWmrp68kHLt8qXZqi0g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddvtddgudduvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeekjeeukeeuveevgfffgffgheejffdvfeeljedtffdugfetjeek gedvtddvfffgveenucffohhmrghinhepghhithhhuhgsrdgtohhmpdguphgukhdrohhrgh enucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 87CA13066565; Mon, 25 May 2020 13:32:06 -0400 (EDT) From: Thomas Monjalon To: "Wiles, Keith" Cc: Jerin Jacob , "Burakov, Anatoly" , Morten =?ISO-8859-1?Q?Br=F8rup?= , Maxime Coquelin , dpdk-dev , "techboard@dpdk.org" , "St Leger, Jim" Date: Mon, 25 May 2020 19:32:05 +0200 Message-ID: <8739815.gXEhDU8P3t@thomas> In-Reply-To: <6E257791-337C-495A-9F23-0F385E5B075F@intel.com> References: <98CBD80474FA8B44BF855DF32C47DC35C60FEA@smartserver.smartshare.dk> <11959277.FkLDZFFinP@thomas> <6E257791-337C-495A-9F23-0F385E5B075F@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 25/05/2020 18:57, Wiles, Keith: > On May 25, 2020, at 11:28 AM, Thomas Monjalon wrote: > > 25/05/2020 18:09, Burakov, Anatoly: > >> On 25-May-20 5:04 PM, Maxime Coquelin wrote: > >>> On 5/25/20 5:59 PM, Burakov, Anatoly wrote: > >>>> On 25-May-20 4:52 PM, Maxime Coquelin wrote: > >>>>> On 5/25/20 5:35 PM, Jerin Jacob wrote: > >>>>>> On May 25, 2020 Thomas Monjalon wrote: > >>>>>>> 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 see > >>>>>> 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/2a4cecf3f2f72346d06990feeb7446b3915d6148 > >>>>> > >>>>> > >>>>> Commit title: " Fix #98530 " > >>>>> Commit message empty, no explanation on what the patch is doing. > >>>>> > >>>>> 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. > >>>>> > >>>> > >>>> Just because they do it wrong doesn't mean we can't do it right :) This > >>>> says more about Microsoft's lack of process around VSCode than it does > >>>> about Github the tool. > >>>> > >>> > >>> True. I was just pointing out that is not the kind of process I would > >>> personally want to adopt. > >>> > >> > >> You won't find disagreement here, but this "process" is not due to the > >> tool. You can just as well allow Thomas to merge stuff without any > >> review because he has commit rights, no Github needed - and you would be > >> faced with the same problem. > >> > >> So, i don't think Jerin was suggesting that we degrade our merge/commit > >> rules. Rather, the point was that (whatever you think of VSCode's > >> review/merge process) there are a lot of pull requests and there is > >> healthy community collaboration. I'm not saying we don't have that, > > > > Yes, recent survey said the process was fine: > > http://mails.dpdk.org/archives/announce/2019-June/000268.html > > IMO the survey is not a great tool for these types of things. The tech board and others that fully understand the process should decide. From my experience using Github or Gitlab is much easy and a single tool to submit patches to a project. Anatoly and others stated it very well and we should convert IMO, as I have always stated in the past. > > > > > >> obviously, but i have a suspicion that we'll get more of it if we lower > >> the barrier for entry (not the barrier for merge!). I think there is a > >> way to lower the secondary skill level needed to contribute to DPDK > >> without lowering coding/merge standards with it. > > > > 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 patches > > to avoid asking them knowing the whole process from the beginning. > > Then frequent contributors get educated on the way. > > > > I think the only real barrier we have is to sign the patch > > with a real name and send an email to right list. > > The ask for SoB real name is probably what started this thread > > in Morten's mind. And the SoB requirement will *never* change. > > Would it not free up your time and energies by have the tools > do most of the work. then you can focus on what matters the patch > and developing more features? No, GitHub is not helping to track root cause and define what should be backported. It does not help to track Coverity issues. It does not add Acks automatically (but patchwork does). It does not send a notification when enough review is done (judgement needed here). It does not split patches when different bugs are fixed. etc... But yes GitHub provides a beautiful interface, and can help with reviews (even if not my taste). One more thing I experience sometimes, GitHub requires only one account for all hosted projects, so it helps leaving quick comments in projects we are not familiar with. > There is a reasons millions of developer use one of these two tools, instead of emailing patch around. We are a fairly small project compared to Linux Kernel and we are not developing code for the Linux kernel. Some of the process like coding standard is great, but the rest is just legacy IMO and not required to get the job done. Having tools to keep track of the minutia should free up more of your time for the real development. > > Yes, it will be a learning curve for some and nailing down the process or rules for merge requests needs to be done. > > All in all it will be a huge improvement for contributors.