提交拉取请求

• 我们建议作者提交范围明确、易于审查的PR，这样在出现问题时也方便回退。因此，作者应避免将多个不相关的修改合并到同一个PR中

• 在提交PR之前，请将您的代码基于main分支的最新版本进行变基操作，您可以通过运行以下命令实现：

  git remote add upstream [url to tvm repo]
  git fetch upstream
  git rebase upstream/main
  

• 确保代码通过lint检查

  # 虽然使用的lint命令应与CI中运行的相同，但此命令能精确重现CI的lint流程
  # （通常有助于调试lint脚本错误或避免手动安装工具）
  python tests/scripts/ci.py lint
  
  # 运行所有lint步骤
  docker/lint.sh
  
  # 若要单独运行某个步骤，请在命令行中指定步骤名称。拼写错误的步骤名
  # 会导致工具打印所有可用步骤
  docker/lint.sh  ...
  

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

  # 对自upstream/main分支以来所有变更的文件运行clang-format检查
  docker/bash.sh ci_lint ./tests/lint/git-clang-format.sh --rev upstream/main
  

• 添加测试用例以覆盖补丁引入的新功能或错误修复。

• 记录您编写的代码，更多信息请参阅Documentation

• Create a pull request 并修复CI检查报告的问题。

• 向其他贡献者请求代码审查，并通过在您的拉取请求中使用@提及他们，根据他们的审查意见改进您的补丁。PR标题中的标签会自动标记订阅用户，因此请确保在PR标题中包含相关主题（例如[microTVM] Add a cool change，而不是a cool change for microTVM）。 请参阅下方的提交信息指南，了解关于PR/提交标题中标签的使用规范以及如何撰写良好的PR/提交信息。

  • 为了让你的代码快速获得审核，我们鼓励你帮助审核他人的代码，这样他们也能投桃报李。

  • 代码审查是一种指导过程，有助于提升贡献者的代码质量。我们应积极主动对待，在审查前尽可能完善代码。我们非常重视那些无需大量审查就能通过的补丁。

  • 详细指南并总结了有用的经验教训。

• 该PR在审阅者批准拉取请求后即可合并。

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

虽然这些准则主要适用于PR的标题和正文信息，但由于GitHub会根据给定分支上的提交自动生成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，也有助于发布人员在生成发布说明时使用；

• 使用祈使语气。避免使用诸如"Added operator X"和"Updated image Y in the CI"这样的标题，而应采用"Add feature X"和"Update image Y in the CI"这样的形式；

• 注意开头字母大小写的正确使用（首字母大写）以及缩略词的大小写，例如TVM、FVP、OpenCL。因此，不要写成“fix tvm use of opencl library”，而应写成“Fix TVM use of OpenCL library”；

• 不要在标题末尾添加句号。

PR/提交正文:

• 确保主体存在（强制要求）；

• 不要在正文中使用Github用户名，如@username（强制要求）；

• 避免使用"项目符号"式的提交信息正文："项目符号"式的提交信息正文本身并无不妥，但若仅包含项目符号而缺乏任何描述或解释，其效果与完全不包含正文描述、缘由或解释的提交信息同样糟糕。

对于轻微偏离这些准则的情况，社区通常会倾向于提醒贡献者注意此政策，而不是回滚或阻止提交/拉取请求。

没有标题和/或正文的提交和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标题和/或正文未正确更新或修正，他们也有权要求作者进行更新。

我们使用Docker镜像来创建可部署到多台机器的稳定CI环境。 按照此问题模板中的步骤 来更新CI Docker镜像。

尽管我们提供了钩子(hooks)来自动为每个拉取请求运行单元测试，但始终建议先在本地运行单元测试，以减轻审阅者的负担并加快审阅流程。

tests/scripts/ci.py 在本地复现CI环境并提供用户友好的界面。 它直接使用CI中相同的Docker镜像和脚本来运行测试。该工具还会将构建结果存放在不同文件夹中， 这样您就可以维护多个测试环境而无需每次都从头开始重建（例如，您可以在保留增量重建的同时测试CPU和i386的更改）。

# 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++测试需要安装gtest，请按照启用C++测试中的说明进行操作

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

./tests/scripts/task_cpp_unittest.sh

必要的依赖项：

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