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 099E4A04EF; Mon, 25 May 2020 17:47:35 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CA4B41D905; Mon, 25 May 2020 17:47:34 +0200 (CEST) Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) by dpdk.org (Postfix) with ESMTP id 00EA91D905 for ; Mon, 25 May 2020 17:47:32 +0200 (CEST) Received: by mail-pj1-f42.google.com with SMTP id s69so114523pjb.4 for ; Mon, 25 May 2020 08:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=vfhmSEbSsdLeUpjsfdLyNRdRUW96+E8sJK4OilXqnbU=; b=UH7CvVeqaCf9B4IoDADXIxdu0RUjt9WJ3Z8QQ1uOdDdsXi9wKyWcbkjqHWg3lQPduA yms1IYUiOucfke64gDbXSMsXQ5k1PRHr4QyPfJqgpyU1B2OpJxpiind33HLodZk5xCcA tGDZKYZ9n+dME/ILg+bLrbk/CPLnapPBXCiAkkbXrrvRTqN7KErafQ18LA7NuTjGPpir EP6s36yQupjJD7+trvBeIITXwewFGRsu/EGFDN868MIikkaf8eIfYqNoDPoQluA8eJ4V ENaJz2eqfMfUFd2x+YyE3+W5JgKvoX+nVGjiNbkieX35V+hljol2waNFr3hwhp74plyz 9acw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=vfhmSEbSsdLeUpjsfdLyNRdRUW96+E8sJK4OilXqnbU=; b=tQ2+12EAt6jxPiotj8Je/iBXyS8bAb6X2HX5/Y3hBVVjfU1XfMgBexL/hqUmXBSDIQ oVwqS8Q+oPKrpJaHCCreadmneoji7PLom9ego0zjzgme1rCARBrEbSZaBkpbD7ES4oAA 1AGlnEH98r27h4q+x9j2SRqQVwl0rs+Wz6PKtkbkqi1KfVXMPXmHb2rM0+cP/0lP8epx LJ22fCcLYTxPVOFw5eXr04ShGXwM8jDnlm2qAZdFnZWfI/2rWvGbEMLPep+Yv5QkXaQN jNPeYBYFNWxUQIcrACZAp+XueUPByzANue9U7RmU5eWvolOd7Eud9Nu3TGL3nG24aY8J vEOQ== X-Gm-Message-State: AOAM5304GXwgHLpzpSlmIyv7KkCeGhCPXCI4LmXGlRcmVJhFSk3bLsj1 sqT7GDIvil3SNhgh4LiWbjnIpA== X-Google-Smtp-Source: ABdhPJzaMHv5EAywSVuxw+IPGB4EooXbm3xAtMYRx/Ek0kDSF9cgzd/uLr4gdIwuWuIFtbvFxkUKsg== X-Received: by 2002:a17:90a:7787:: with SMTP id v7mr22224021pjk.199.1590421652021; Mon, 25 May 2020 08:47:32 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id 73sm11806295pge.15.2020.05.25.08.47.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 May 2020 08:47:31 -0700 (PDT) Date: Mon, 25 May 2020 08:47:23 -0700 From: Stephen Hemminger To: Bruce Richardson Cc: "Burakov, Anatoly" , Morten =?UTF-8?B?QnI=?= =?UTF-8?B?w7hydXA=?= , techboard@dpdk.org, dev@dpdk.org, "Jim St. Leger" Message-ID: <20200525084723.37fc5dde@hermes.lan> In-Reply-To: <20200525120819.GA900@bricha3-MOBL.ger.corp.intel.com> References: <98CBD80474FA8B44BF855DF32C47DC35C60FEA@smartserver.smartshare.dk> <6d59a42a-915b-47fc-60e6-94a4600d4bff@intel.com> <20200525120819.GA900@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 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, 25 May 2020 13:08:19 +0100 Bruce Richardson wrote: > On Mon, May 25, 2020 at 12:12:49PM +0100, Burakov, Anatoly wrote: > > On 25-May-20 10:34 AM, Morten Br=C3=B8rup wrote: =20 > > > Dear DPDK Techboard, > > >=20 > > > I am writing this to raise awareness about the environment for contri= buting to DPDK, as I feel that it could be improved. This is not a personal= thing - I have thick skin - but a general observation. I urge the DPDK Tec= hboard to spend some time to focus on the process, and not only on the tech= nology. > > >=20 > > > Contributing to DPDK is not easy for infrequent contributors: > > >=20 > > > 1. Infrequent contributors are limited by not being deeply familiar w= ith the coding style and the commit style, so their style is not always 100= % spot on. > > > 2. Infrequent contributors are limited by not having built trust by t= he maintainers and frequent contributors, and thus their contributions unde= rgo more detailed reviews and get more negative (or: perceived negative) fe= edback, where trusted contributors are given more slack. (In theory, every = contribution should be treated equal, but in reality it makes sense allocat= ing fewer resources to review contributions from developers with a proven t= rack record.) > > > 3. Infrequent contributors may not be deeply familiar with the develo= pment/contribution tools. E.g. how to use git the "DPDK way". > > >=20 > > > Additionally, when contributing to old DPDK code, checkpatch complain= s about coding style violations stemming from the existing old code. This a= lso raises the barrier and decreases the motivation to contribute - a contr= ibutor getting negative feedback about something he didn't even do. > > >=20 > > >=20 > > > Here are a couple of anonymous examples from the mailing list: > > >=20 > > > An infrequent contributor got minor coding style suggestions to a pat= ch, although the coding style was similar to that of a closely related func= tion in the same library, but not perfectly matching the official coding st= yle. I think we could be more lax about coding style, except if the coding = style directly violates automatic coding style validation tools. > > > =20 > >=20 > > A lot of that could simply be fixed by codifying our Coding Style into a > > .clang-format file, and make this process (semi-)automatic. A lot of > > IDE's/editors now have either built-in support for clang-format, or have > > plugins enabling said support. > >=20 > > I've investigated this in the past and found that our coding style > > guidelines are very specific in some places, and neither clang-format n= or > > other options have that kind of detailed control over source code > > formatting. The only other option would be to adjust our coding style t= o fit > > the options available in clang-format. > >=20 > > IMO this would cut down a lot on complaints about mixing indents, wrong > > alignment, (lack of) newlines before function name, etc. > > =20 >=20 > This is of definite interest to me, for one. How close to our current > standards can we get right now with clang-format? If the coding standards > right now can't match exactly, how big would be the changes to make them > doable in clang-format? Is it one or two things, or is it quite a number? >=20 > /Bruce Or just adjust the coding style to match a clang format. For a positive example of a project that does this see VPP. They have: make checkstyle and make fixstyle And their CI bot checks it.