On Mon, May 25, 2020 at 08:47:23AM -0700, Stephen Hemminger wrote: > On Mon, 25 May 2020 13:08:19 +0100 > Bruce Richardson <bruce.richard...@intel.com> 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 > > 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.
Yes, that was what I was implying by asking how big the delta was. :-) If there are just a couple of things that don't quite align, the benefit of getting clang-format outweighs the downsides of tweaking our coding standards, IMHO.
