Skip to content

Latest commit

 

History

History
127 lines (101 loc) · 5.41 KB

CONTRIBUTING.md

File metadata and controls

127 lines (101 loc) · 5.41 KB
Raw

Contribution Guidelines

Contributions that fix documentation errors or that make small changes to existing code can be contributed directly by following the rules below and submitting an appropriate PR.

Contributions intended to add significant new functionality must follow a more collaborative path described in the following points. Before submitting a large PR that adds a major enhancement or extension, be sure to submit a GitHub issue that describes the proposed change so that the Triton team can provide feedback.

  • As part of the GitHub issue discussion, a design for your change will be agreed upon. An up-front design discussion is required to ensure that your enhancement is done in a manner that is consistent with Triton's overall architecture.

  • The Triton project is spread across multiple repos. The Triton team will provide guidance about how and where your enhancement should be implemented.

  • Testing is a critical part of any Triton enhancement. You should plan on spending significant time on creating tests for your change. The Triton team will help you to design your testing so that it is compatible with existing testing infrastructure.

  • If your enhancement provides a user visible feature then you need to provide documentation.

Contribution Rules

  • The code style convention is enforced by clang-format. See below on how to ensure your contributions conform. In general please follow the existing conventions in the relevant file, submodule, module, and project when you add new code or when you extend/fix existing functionality.

  • Avoid introducing unnecessary complexity into existing code so that maintainability and readability are preserved.

  • Try to keep pull requests (PRs) as concise as possible:

    • Avoid committing commented-out code.

    • Wherever possible, each PR should address a single concern. If there are several otherwise-unrelated things that should be fixed to reach a desired endpoint, it is perfectly fine to open several PRs and state in the description which PR depends on another PR. The more complex the changes are in a single PR, the more time it will take to review those changes.

    • Make sure that the build log is clean, meaning no warnings or errors should be present.

  • Make sure all L0_* tests pass:

    • In the qa/ directory, there are basic sanity tests scripted in directories named L0_.... See the Test documentation for instructions on running these tests.

  • Triton Inference Server's default build assumes recent versions of dependencies (CUDA, TensorFlow, PyTorch, TensorRT, etc.). Contributions that add compatibility with older versions of those dependencies will be considered, but NVIDIA cannot guarantee that all possible build configurations work, are not broken by future contributions, and retain highest performance.

  • Make sure that you can contribute your work to open source (no license and/or patent conflict is introduced by your code). You need to complete the CLA described below before your PR can be merged.

  • Thanks in advance for your patience as we review your contributions; we do appreciate them!

Coding Convention

Use clang-format to format all source files (*.h, *.cc, *.proto, *.py) to a consistent format. You should run clang-format on all source files before submitting a pull request:

$ apt-get install clang-format clang-format-6.0

For convenience there is a format.py script in the triton-inference-server/common repo in the "tools" directory that can be used to clang-format all files within the repo:

$ python3 ../common/tools/format.py *

Contributor License Agreement (CLA)

Triton requires that all contributors (or their corporate entity) send a signed copy of the Contributor License Agreement to [email protected].