提交 Pull Request

准则 

我们建议作者发送范围明确的 PR，这些 PR 易于审查，并且在出现问题时易于回退。因此，作者应避免将多个不相关的更改合并到单个 PR 中
在您提交 PR 之前，请将您的代码 rebase 到最新的 main 版本，您可以通过运行以下命令来执行此操作
```
git remote add upstream [url to tvm repo]
git fetch upstream
git rebase upstream/main
```

确保代码通过 lint 检查

# While the lint commands used should be identical to those run in CI, this command reproduces
# the CI lint procedure exactly (typically helpful for debugging lint script errors or
# to avoid installing tools manually)
python tests/scripts/ci.py lint

# Run all lint steps.
docker/lint.sh

# To run steps individually, specify their step names on the command-line. An incorrectly
# spelled step name causes the tool to print all available steps.
docker/lint.sh <step_name> ...

如果 clang-format lint 检查失败，请按如下方式运行 git-clang-format 以自动重新格式化您的代码

# Run clang-format check for all the files that changed since upstream/main
docker/bash.sh ci_lint ./tests/lint/git-clang-format.sh --rev upstream/main

添加测试用例以覆盖补丁引入的新功能或错误修复。
记录您编写的代码，更多信息请参见文档
创建 pull request 并修复 CI 检查报告的问题。
向其他贡献者请求代码审查，并通过在您的 pull request 中 @ 他们来根据他们的审查改进您的补丁。PR 标题中的标签将自动标记订阅用户，因此请确保在您的 PR 标题中放入相关主题（例如 [microTVM] 添加一个很酷的更改 而不是 针对 microTVM 的一个很酷的更改）。请参阅下面的提交消息准则，了解有关 PR/提交标题中标签的准则以及如何编写良好的 PR/提交消息。
- 为了使您的代码得到快速审查，我们鼓励您帮助审查他人的代码，以便他们可以反过来帮助您。
- 代码审查是一个指导过程，有助于提高贡献者的代码质量。我们应该积极主动地对待它，以便在审查之前尽可能地改进代码。我们高度重视无需大量审查即可通过的补丁。
- 详细的准则并总结了有用的经验教训。
在审查者批准 pull request 后，PR 可以被合并。

提交消息准则 

Apache TVM 使用 Github (GH) 平台通过 Pull Request (PR) 进行补丁提交和代码审查。合并到 Apache TVM 主树中的最终提交（标题和正文）由 PR 的标题和正文组成，并且必须保持更新，并根据审查和讨论反映代码中的新更改。

尽管这些准则主要适用于 PR 的标题和正文消息，但由于 GH 从给定分支上的提交自动生成 PR 的标题和正文，因此建议从一开始就遵循这些准则，在准备通常要提交给 Apache TVM 项目的提交时。这将简化新 PR 的创建，避免返工，并有助于审查。

以下规则将有助于实现统一性，这对于审查和整个代码库维护都有好处，帮助您编写高质量的提交消息，适用于 Apache TVM 项目，从而可以快速进行日志搜索、二分法查找等等。

PR/提交标题:

保证标题存在（强制执行）；

请勿在标题中使用 Github 用户名，例如 @username（强制执行）；

必须存在标签，以提示 PR/提交“触及”的代码的组件（强制执行）。例如 [BugFix]、[CI]、[microTVM] 和 [TVMC]。标签位于方括号之间，并首先出现在标题中。如果存在多个标签，则应使用多个括号，例如 [BugFix][CI]。通常，标签推荐使用大驼峰命名法。例如，优先使用 [Fix]、[BugFix] 和 [Docker] 而不是 [fix]、[bug_fix] 和 [docker] 形式。首字母缩略词应保持原样，因此，例如，使用 [CI] 和 [TVMC] 而不是 [ci] 和 [tvmc]。标签帮助审查者识别他们可以/想要审查的 PR，并在生成发布说明时帮助发布人员；

使用祈使语气。避免使用“添加了运算符 X”和“在 CI 中更新了图像 Y”之类的标题，而应使用“添加功能 X”和“在 CI 中更新图像 Y”之类的形式；

注意正确使用首字母大写（第一个字母大写）和首字母缩略词，例如 TVM、FVP、OpenCL。因此，不要写成“fix tvm use of opencl library”，而是写成“Fix TVM use of OpenCL library”；

请勿在标题末尾添加句点。

PR/提交正文:

保证正文存在（强制执行）；

请勿在正文文本中使用 Github 用户名，例如 @username（强制执行）；

避免“要点”式提交消息正文：“要点”式提交消息正文本身并不差，但是没有任何描述或解释的“要点”式提交消息可能与正文中没有任何描述、理由或解释的提交一样糟糕。

对于偏离这些准则的细微之处，社区通常会倾向于提醒贡献者此政策，而不是回退或阻止提交/PR。

没有标题和/或正文的提交和 PR 不被视为对这些准则的细微偏离，因此必须避免。

最重要的是，提交消息的内容，尤其是正文，应旨在传达更改的意图，因此应避免含糊不清。例如，应避免使用标题如“修复”、“清理”和“修复不稳定的测试”且没有任何正文文本的提交。此外，对于审查，这将使审查者想知道究竟修复或更改了什么以及为什么需要进行更改，从而减慢审查速度。

以下是一个可以作为模型的示例

[microTVM] Zephyr: Remove zephyr_board option from build, flash, and open_transport methods

Currently it’s necessary to pass the board type via ‘zephyr_board’ option to
the Project API build, flash, and open_transport methods.

However, since the board type is already configured when the project is
created (i.e. when the generate_project method is called), it’s possible to
avoid this redundancy by obtaining the board type from the project
configuration files.

This commit adds code to obtain the board type from the project CMake files,
removing this option from build, flash, and open_transport methods, so it’s
only necessary to specify the ‘zephyr_board’ option when calling
generate_project.

This commit also moves the ‘verbose’ and ‘west_cmd’ options from ‘build’
method to ‘generate_project’, reducing further the number of required options
when building a project, since the ‘build’ method is usually called more often
than the ‘generate_project’.

在创建新的 PR 并开始审查后，审查者通常会请求更改。通常，作者将处理审查者的意见，并在初始提交之上推送其他提交。对于这些其他提交，没有关于提交消息的建议。但是，如果其他提交使 PR 标题和/或正文过时，则作者有责任使 PR 标题和正文与代码中的新更改保持同步，并相应地更新 PR 标题和正文（请记住，PR 标题和正文将用于组成最终提交消息，该消息将落入主树中）。

提交者将寻求在提交之前修复提交消息的任何问题，但他们保留告知作者规则并鼓励他们在将来遵循这些规则的权利。此外，当 PR 标题和/或正文未正确更新或修复时，他们保留要求作者更新 PR 标题和/或正文的权利。

# see all available platforms
python tests/scripts/ci.py --help
python tests/scripts/ci.py cpu --help

# run the CPU build in the ci_cpu docker container (build will be left in
# the build-cpu/ folder)
# note: the CPU and GPU Docker images are quite large and may take some
# time to download on their first use
python tests/scripts/ci.py cpu

# run the CPU build in the ci_cpu docker container and then run unittests
python tests/scripts/ci.py cpu --unittest

# quickly iterate by running a specific test and skipping the rebuild each time
python tests/scripts/ci.py cpu --skip-build --tests tests/python/tir-transform/test_tir_transform_inject_rolling_buffer.py::test_upscale

# run the CPU build and drop into a shell in the container
python tests/scripts/ci.py cpu --interactive

我们会定期更新我们的 docker 镜像，并且随着时间的推移，陈旧的镜像可能会不必要地消耗磁盘空间。您可以使用以下命令删除当前检出分支以及任何其他工作树中未使用的陈旧镜像

docker/clear-stale-images.sh

有关更多选项，请查阅 --help。

C++ (本地)

运行 C++ 测试需要安装 gtest，请按照启用 C++ 测试中的说明进行操作

# assume you are in tvm source root
TVM_ROOT=`pwd`

./tests/scripts/task_cpp_unittest.sh

Python (本地)

必要的依赖项

pip install --user pytest Cython

如果您想运行所有测试

# build tvm
make

./tests/scripts/task_python_unittest.sh

如果您想运行单个测试

# build tvm
make

# let python know where to find tvm related libraries
export PYTHONPATH=python
rm -rf python/tvm/*.pyc python/tvm/*/*.pyc python/tvm/*/*/*.pyc

TVM_FFI=ctypes python -m pytest -v tests/python/unittest/test_pass_storage_rewrite.py

# Additionally if you want to run a single test, for example test_all_elemwise inside a file.
TVM_FFI=ctypes python -m pytest -v -k "test_all_elemwise" tests/python/frontend/tflite/test_forward.py

提交 Pull Request

准则 

提交消息准则 

CI 环境 

测试 

Docker (推荐)

C++ (本地)

Python (本地)

提交 Pull Request

准则

提交消息准则

CI 环境

测试

Docker (推荐)

C++ (本地)

Python (本地)

准则 

提交消息准则 

CI 环境 

测试 