All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: 周洪锋 <hfzhou369@163.com>
Cc: linux-rdma@vger.kernel.org
Subject: Re: Clarification on rdma-core Code Style and Contribution Guidelines
Date: Mon, 12 May 2025 13:17:51 +0300	[thread overview]
Message-ID: <20250512101751.GB22843@unreal> (raw)
In-Reply-To: <2442ea1c.5bd5.196a9714b5b.Coremail.hfzhou369@163.com>

On Wed, May 07, 2025 at 02:31:36PM +0800, 周洪锋 wrote:
> 
> 
> Dear Maintainers,
> 
> 
> I hope this message finds you well.
> 
> 
> I'm Zhou Hongfeng from BitIntelligence, a network company from China, and I’m interested in contributing to rdma-core. While preparing my patches, I want to ensure my code adheres to the project’s style guidelines. However, I noticed a few uncertainties regarding the current practices:
> 
> 
>   `.clang-format` Usage: The repository includes a .clang-format file, but it hasn’t been updated in a while. When I ran clang-format-11) on the existing codebase, nearly all files showed formatting differences. This suggests the config might not fully align with the actual code style. Is `clang-format` the recommended tool for enforcing style consistency? If so, is there an updated version of the config file that maintainers endorse?

We follow kernel coding style in rdma-core too, but some code was
written before we adopted this policy. So the guidelines are relatively
simple: use kernel style for new files, and "existing to that file" for
changes in already existing codebase.

> 
> 
>   Manual Style Rules: If the project prioritizes manual style enforcement over automated tools, could you point me to documented conventions (e.g., indentation, naming, comments)?
> 
> 
>   Pre-Submission Handling: Should contributors manually match the existing style, or is it acceptable to submit patches reformatted with an updated .clang-format?

Sure, it is perfectly fine to extend existing .clang-format.

> 
> 
> Additionally, if there are other contribution guidelines (e.g., commit message format, testing requirements), I’d appreciate any pointers to avoid unnecessary review overhead.

Kernel coding style, pyverbs tests coverage and +1 from CI.

Thanks

> 
> 
> Thank you for your time and guidance! I’m happy to adjust my workflow to align with the project’s standards. Looking forward to your insights.
> 
> 
> Best regards,
> Zhou Hongfeng
> Github.com/zhf999

      reply	other threads:[~2025-05-12 10:17 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-07  6:31 Clarification on rdma-core Code Style and Contribution Guidelines 周洪锋
2025-05-12 10:17 ` Leon Romanovsky [this message]

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=20250512101751.GB22843@unreal \
    --to=leon@kernel.org \
    --cc=hfzhou369@163.com \
    --cc=linux-rdma@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.