incubator-nuttx/CONTRIBUTING.md

Contributing to Apache NuttX RTOS

Hi! Thank you for your interest in contributing to Apache NuttX RTOS :-)

Guidelines

To help us successfully review your contribution, it is very important that you follow these guidelines.

If you need more information please read the Full Contributing Documentation.

Coding Standard

• You should follow NuttX C Coding Standard.

• Your code will be automatically checked by GitHub Continuous Integration (CI) system. If you see the "check" step fails, it is possible that this happens due to style errors.

• Note that we require you to solve these issues and adapt all modified files even if you didn't introduce the problem yourself (this way, every contribution gets us closer to compliance).

Commits

• Each commit must contain a meaningful commit message that consist of:

  • topic (mandatory).
  • description (optional, separate with blank line from topic).

• Prefix commit topic with a functional context (i.e. sched: Fixed compiler warning.).

• Provide only signed commits (git commit -s) with valid author and email fields.

• Valid commit message example:

  net/can: Add g_ prefix to can_dlc_to_len and len_to_can_dlc.
  
  Add g_ prefix to can_dlc_to_len and len_to_can_dlc to
  follow NuttX coding style conventions for global symbols,
  improving code readability and maintainability.
  * you can also use bullet points.
  * to note different thing briefly.
  
  Signed-off-by: AuthorName <Valid@EmailAddress>
  

• If you create a proper commit message as explained above, the first line will be automatically used as pull-request title and the rest is added as description. Use it as a starting point to describe your Pull-Request (PR).

Pull Requests

• Be sure to fill in the pull-request report with meaningful content. Be very descriptive, take your time. Good explanation, as for someone who can see the issue for the first time, will help understand the change and improve the assessment process. Please provide short descriptions even for a trivial change.

  • Summary: It is important to provide information on why change is necessary, what it exactly does and how, if new feature shows up, provide references (dependencies, similar problems and solutions), etc.

  • Impact: State how (where applicable) that change affects users, build process, hardware, documentation, security, compatibility, etc.

  • Testing: Please provide details on how did you verify the change, what Host was used for build (OS, CPU, compiler, ..), what Target was used for verification (arch, board:config, ..), etc. Providing build and runtime logs from before and after change is highly appreciated.

• Introduce only one functional change per pull-request.

• Provide finished and verified solutions. Clearly mark Work-In-Progress pull requests not yet ready for assessment.

References

Example Pull Request Report

Summary

• Why change is necessary (fix, update, new feature)?
• What functional part of the code is being changed?
• How does the change exactly work (what will change and how)?
• Related NuttX Issue reference if applicable.
• Related NuttX Apps Issue / Pull Request reference if applicable.

Impact

• Is new feature added? Is existing feature changed?
• Impact on user (will user need to adapt to change)? NO / YES (please describe if yes).
• Impact on build (will build process change)? NO / YES (please descibe if yes).
• Impact on hardware (will arch(s) / board(s) / driver(s) change)? NO / YES (please describe if yes).
• Impact on documentation (is update required / provided)? NO / YES (please describe if yes).
• Impact on security (any sort of implications)? NO / YES (please describe if yes).
• Impact on compatibility (backward/forward/interoperability)? NO / YES (please describe if yes).
• Anything else to consider?

Testing

I confirm that changes are verified on local setup and works as intended:

• Build Host(s): OS (Linux,BSD,macOS,Windows,..), CPU(Intel,AMD,ARM), compiler(GCC,CLANG,version), etc.
• Target(s): arch(sim,RISC-V,ARM,..), board:config, etc.

Testing logs before change:

runtime / build logs before change goes here

Testing logs after change:

runtime / build logs after change goes here

How to repeat: * you can also provide steps on how to reproduce problem and verify the change.

PR verification

• This PR introduces only one functional change.
• I have updated all required description fields above.
• My PR adheres to Contributing Guidelines and Documentation (git commit title and message, coding standard, etc).
• My PR is still work in progress (not ready for review).
• My PR is ready for review and can be safely merged into a codebase.