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
