DPDK patches and discussions
 help / color / mirror / Atom feed
From: Jerin Jacob <jerinjacobk@gmail.com>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Cc: "Bruce Richardson" <bruce.richardson@intel.com>,
	"Morten Brørup" <mb@smartsharesystems.com>,
	techboard@dpdk.org, dpdk-dev <dev@dpdk.org>,
	"Jim St. Leger" <jim.st.leger@intel.com>
Subject: Re: [dpdk-dev] [dpdk-techboard] Consider improving the DPDK contribution processes
Date: Mon, 25 May 2020 20:58:32 +0530	[thread overview]
Message-ID: <CALBAE1NXpXYuxWEzpB_NpxMiNvZ-SFmhjRWmjHrZuXaThpj=aA@mail.gmail.com> (raw)
In-Reply-To: <d7cc1b0f-b4c2-da63-5416-ac4b5ca77a95@intel.com>

On Mon, May 25, 2020 at 8:34 PM Burakov, Anatoly
<anatoly.burakov@intel.com> 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ørup wrote:
> >>> Dear DPDK Techboard,
> >>>
> >>> I am writing this to raise awareness about the environment for contributing 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 Techboard to spend some time to focus on the process, and not only on the technology.
> >>>
> >>> Contributing to DPDK is not easy for infrequent contributors:
> >>>
> >>> 1. Infrequent contributors are limited by not being deeply familiar with 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 the maintainers and frequent contributors, and thus their contributions undergo more detailed reviews and get more negative (or: perceived negative) feedback, where trusted contributors are given more slack. (In theory, every contribution should be treated equal, but in reality it makes sense allocating fewer resources to review contributions from developers with a proven track record.)
> >>> 3. Infrequent contributors may not be deeply familiar with the development/contribution tools. E.g. how to use git the "DPDK way".
> >>>
> >>> Additionally, when contributing to old DPDK code, checkpatch complains about coding style violations stemming from the existing old code. This also raises the barrier and decreases the motivation to contribute - a contributor 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 patch, although the coding style was similar to that of a closely related function in the same library, but not perfectly matching the official coding style. 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 have
> >> 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, wrong
> >> 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 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?
> >
> > /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 DPDK.

[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

  reply	other threads:[~2020-05-25 15:28 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-25  9:34 [dpdk-dev] " Morten Brørup
2020-05-25 11:00 ` Jerin Jacob
2020-05-25 11:12 ` Burakov, Anatoly
2020-05-25 11:58   ` Jerin Jacob
2020-05-25 12:53     ` Thomas Monjalon
2020-05-25 14:28       ` Burakov, Anatoly
2020-05-25 14:55         ` Wiles, Keith
2020-05-25 15:22         ` Thomas Monjalon
2020-05-25 15:35           ` Jerin Jacob
2020-05-25 15:52             ` [dpdk-dev] [dpdk-techboard] " Maxime Coquelin
2020-05-25 15:59               ` Burakov, Anatoly
2020-05-25 16:04                 ` Maxime Coquelin
2020-05-25 16:09                   ` Burakov, Anatoly
2020-05-25 16:28                     ` Thomas Monjalon
2020-05-25 16:57                       ` Wiles, Keith
2020-05-25 17:32                         ` Thomas Monjalon
2020-05-25 17:50                           ` Wiles, Keith
     [not found]                             ` <068c6367-b233-07f9-c038-4bddc4f48106@kth.se>
2020-05-26  9:33                               ` Burakov, Anatoly
2020-05-26 13:12                                 ` Wiles, Keith
2020-05-26 13:10                               ` Wiles, Keith
2020-05-25 18:44                       ` [dpdk-dev] [dpdk-techboard] Consider improving the DPDKcontribution processes Morten Brørup
2020-05-25 20:34                         ` Thomas Monjalon
2020-05-26  7:06                           ` Tom Barbette
2020-05-26  7:31                             ` Maxime Coquelin
2020-05-26  9:13                               ` Burakov, Anatoly
2020-05-26  9:43                         ` Burakov, Anatoly
2020-05-26 10:16                           ` Jerin Jacob
2020-05-26 10:33                             ` Thomas Monjalon
2020-05-26 10:52                               ` Burakov, Anatoly
2020-05-26 12:45                                 ` Thomas Monjalon
2020-05-26 13:57                                   ` Burakov, Anatoly
2020-05-26 14:01                                     ` Thomas Monjalon
2020-05-26 10:53                               ` Jerin Jacob
2020-05-25 16:01               ` [dpdk-dev] [dpdk-techboard] Consider improving the DPDK contribution processes Jerin Jacob
2020-05-25 15:43           ` [dpdk-dev] " Burakov, Anatoly
2020-05-25 14:55       ` Wiles, Keith
2020-05-25 12:08   ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
2020-05-25 15:04     ` Burakov, Anatoly
2020-05-25 15:28       ` Jerin Jacob [this message]
2020-05-25 15:47     ` Stephen Hemminger
2020-05-25 16:21       ` Bruce Richardson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALBAE1NXpXYuxWEzpB_NpxMiNvZ-SFmhjRWmjHrZuXaThpj=aA@mail.gmail.com' \
    --to=jerinjacobk@gmail.com \
    --cc=anatoly.burakov@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=jim.st.leger@intel.com \
    --cc=mb@smartsharesystems.com \
    --cc=techboard@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).