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 14615A04EF; Mon, 25 May 2020 17:28:51 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7A8851D5B0; Mon, 25 May 2020 17:28:50 +0200 (CEST) Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) by dpdk.org (Postfix) with ESMTP id 0086A2C02; Mon, 25 May 2020 17:28:48 +0200 (CEST) Received: by mail-io1-f54.google.com with SMTP id u23so5833118iot.12; Mon, 25 May 2020 08:28:48 -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=Z+mPkgEebCF19DSNJrABRD7Ek8A3f2hDs22Txo8Tids=; b=Gabe+NMZsoJZVTl7oxiINGcu0a5blAFvpW/hJTcP2lId6clyeRB/Af0iSQV+4rpr6v pl/I+VNn7wOmeUjq/WUibFTKt6gB0A2gI+aqMKoR/pY2sE4/BK4VuVux6ENtEBepHuHe w1pICxn18oQPfTEKtaKRDLn4pGYgHgAKVZjuyNbZ1EapPd5DC2zLy2p6AT3sXLBuK9fC Zv7UwFcB+wyYxk39XjfwEPnVYcbqN9phmqI5oFnXTD3YDdMBb5K5tzE8zwxM4O0fXgbz rFoZIHEDuL9D2lnBIEFtakBWij8xujeTuT5y/OxgvkGq+HCeq4yBD9p8SodaJYpig7bh cS1Q== 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=Z+mPkgEebCF19DSNJrABRD7Ek8A3f2hDs22Txo8Tids=; b=fk1t/Ri9wJcb4s43pcAiClbrTLgNXghVzC6xjHCZDA7QhDjbgXeVY7U0fQLsGbtqg7 AKBZheKdah/ceUX8UH2JsKLmMFhnARkSifWx4u4saP9W3HeOgaNS5pySNKmIXxHQ3Giu hrNWqmA5f+SAcuAk3ffBpprYjiR1vt0hwDiSFWsJD/nBcZXDyrfdIZJVi7qot5bQjbsO 5gv52+C+n8jvXVuS5pjDy34km+6cUB/iZQ0w58t1ouyh7GH0r6QBbpTnu8yNlRKW9qnV WZ3cFMKHe5oCTWLcttxlLSQf/q93mFv68vmt4gJKyoXQPyEY0ZZEpocjCE/ekXwN6za6 xj9A== X-Gm-Message-State: AOAM530KwJjFIp0hIQlAF4gZv98fRvIi3w/6vEo7KCT5D+jEVYHugtW1 juzWGIhPcVRQyCHgY22EolR5B9v4lxYy/Pnmwiw= X-Google-Smtp-Source: ABdhPJwiRI1Rri7rlXv053PsIx9I4I7+vydYQpP+10YlhXNvGw250QCZsQlL4mO0/TMEipIdEZ6zigk5jF2IXOolNkU= X-Received: by 2002:a6b:1543:: with SMTP id 64mr14113054iov.123.1590420528026; Mon, 25 May 2020 08:28:48 -0700 (PDT) MIME-Version: 1.0 References: <98CBD80474FA8B44BF855DF32C47DC35C60FEA@smartserver.smartshare.dk> <6d59a42a-915b-47fc-60e6-94a4600d4bff@intel.com> <20200525120819.GA900@bricha3-MOBL.ger.corp.intel.com> In-Reply-To: From: Jerin Jacob Date: Mon, 25 May 2020 20:58:32 +0530 Message-ID: To: "Burakov, Anatoly" Cc: Bruce Richardson , =?UTF-8?Q?Morten_Br=C3=B8rup?= , techboard@dpdk.org, dpdk-dev , "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 8:34 PM Burakov, Anatoly wrote: > > On 25-May-20 1:08 PM, 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: > >>> Dear DPDK Techboard, > >>> > >>> 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. > >>> > >>> Contributing to DPDK is not easy for infrequent contributors: > >>> > >>> 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". > >>> > >>> 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. > >>> > >>> > >>> Here are a couple of anonymous examples from the mailing list: > >>> > >>> 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. > >>> > >> > >> 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 ha= ve > >> plugins enabling said support. > >> > >> I've investigated this in the past and found that our coding style > >> guidelines are very specific in some places, and neither clang-format = nor > >> other options have that kind of detailed control over source code > >> formatting. The only other option would be to adjust our coding style = to fit > >> the options available in clang-format. > >> > >> IMO this would cut down a lot on complaints about mixing indents, wron= g > >> alignment, (lack of) newlines before function name, etc. > >> > > > > 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 standar= ds > > right now can't match exactly, how big would be the changes to make the= m > > doable in clang-format? Is it one or two things, or is it quite a numbe= r? > > > > /Bruce > > > > The issues weren't that serious - mainly the peculiarities around our > custom macros like __rte_experimental or our specific flavor of > indentation. I can't remember off the top of my head exactly what was > the problem as i've looked at this a couple of years ago, but i'm pretty > sure the majority of the stuff we expect in DPDK is configurable through > clang-format. Plus, i'm sure clang-format has gained features in the > meantime, maybe the things that weren't possible then, are now :) I have been using the following clang-format configuration for DPDK[1]. I dont see any setbacks. ForEachMacros section below needs to extend for DP= DK. [1] "{ BasedOnStyle: LLVM, IndentWidth: 8, TabWidth: 8, UseTab: Always, AllowShortIfStatementsOnASingleLine: false, IndentCaseLabels: false, ColumnLimit: 80, AllowShortFunctionsOnASingleLine: false, AlwaysBreakAfterReturnType: AllDefinitions, ColumnLimit: 80, ConstructorInitializerAllOnOneLineOrOnePerLine: true, ConstructorInitializerIndentWidth: 8, ContinuationIndentWidth: 8, BreakBeforeBraces: Linux, AllowShortBlocksOnASingleLine: false, AlignConsecutiveAssignments: false, AlignEscapedNewlines: Right, AlignConsecutiveMacros : true, MaxEmptyLinesToKeep : 1, Cpp11BracedListStyle : true, AlignTrailingComments : true, ForEachMacros: ['STAILQ_FOREACH', 'rte_graph_foreach_node', 'TAILQ_FOREACH', 'RTE_ETH_FOREACH_DEV']}", > > -- > Thanks, > Anatoly