[v0.10.0->0.13.0]Task[2,3,4] Contribute (#213)

Co-authored-by: sparanoid <[email protected]>
hyperai · Nov 23, 2023 · 8878bd3 · 8878bd3
1 parent 5a4d3fc
commit 8878bd3
Show file tree

Hide file tree

Showing 5 changed files with 63 additions and 9 deletions.
diff --git a/docs/contribute/ci.md b/docs/contribute/ci.md
@@ -92,7 +92,24 @@ git push my_repo
 
 ### Docker 镜像
 
-所有 CI 任务都在 Docker 容器（由 [docker/](https://github.com/apache/tvm/tree/main/docker) 文件夹中的文件构建）中运行其大部分的工作。这些文件通过 [docker-images-ci](https://ci.tlcpack.ai/job/docker-images-ci/) 任务每日在 Jenkins 中构建。这些容器的镜像在 [tlcpack Docker Hub](https://hub.docker.com/u/tlcpack) 中托管，并在 [Jenkinsfile.j2](https://github.com/apache/tvm/tree/main/Jenkinsfile.j2) 中引用。这些镜像可用标准的 Docker 命令在本地检查和运行。
+所有 CI 任务都在 Docker 容器（由 [docker](https://github.com/apache/tvm/tree/main/docker) 文件夹中的文件构建）中运行其大部分的工作。
+
+#### 更新 Docker 镜像标签
+
+要更新标签，需要构建一个新的镜像并上传到 Docker Hub，然后需要更新 [docker-images.ini](https://github.com/apache/tvm/tree/main/ci/jenkins/docker-images.ini) 文件中的镜像标签，以匹配 Docker Hub 上的镜像标签。
+
+Docker 镜像会每晚自动构建，通过 [docker-images-ci](https://ci.tlcpack.ai/job/docker-images-ci/) 来实现，一旦它们通过 CI 测试，就会上传到 https://hub.docker.com/u/tlcpackstaging。合并后的 CI 在 main 上构建 Docker 镜像并将其上传到 tlcpackstaging Docker Hub 帐户。tlcpackstaging Docker 镜像会自动晋升到tlcpack 帐户。这意味着tlcpackstaging 中的镜像标签可以在 CI 中使用，并且在 main 上成功合并后将自动移动到 tlcpack。因此，更新镜像的步骤如下：
+
+合并一个更改docker/下的 Dockerfile 或docker/install中脚本的 PR。
+
+执行以下操作之一：
+
+a. 等待 PR 中的合并后 CI 构建完成，并将新构建的镜像上传到 [tlcpackstaging](https://hub.docker.com/u/tlcpackstaging) Docker Hub。
+b. 等待每晚的 Docker 镜像构建完成，并将新构建的镜像上传到 [tlcpackstaging](https://hub.docker.com/u/tlcpackstaging) Docker Hub。
+
+找到tlcpackstaging Docker Hub 上新上传的镜像标签，例如20221208-070144-22ff38dff，然后将ci/jenkins/docker-images.ini 中的标签更新为使用 tlcpackstaging 标签，但在 tlcpack 帐户下，例如tlcpack/ci-arm:20221208-070144-22ff38dff。提交一个包含这些更改的 PR，并等待它通过 CI 测试以确保新的镜像有效。
+
+合并docker-images.ini 更新的 PR。一旦合并后的 CI 在main 上运行完成，tlcpackstaging 标签将自动重新上传到tlcpack。
 
 ### ci-docker-staging
 

diff --git a/docs/contribute/code_guide.md b/docs/contribute/code_guide.md
@@ -70,6 +70,11 @@ def test_mytest(target, dev):
 
 用 `target="llvm"`、`target="cuda"` 和其他几个运行 `test_mytest`。这可以确保测试由 CI 在正确的硬件上运行。如果只想针对几个 target 进行测试，请使用 `@tvm.testing.parametrize_targets("target_1", "target_2")`。如果想在单个 target 上进行测试，请使用来自 `tvm.testing()` 的相关装饰器。例如，CUDA 测试使用 `@tvm.testing.requires_cuda` 装饰器。
 
+## 网络资源
+在 CI 中，从互联网下载文件是导致测试失败的一个主要原因（例如，远程服务器可能宕机或速度较慢），因此在测试期间尽量避免使用网络。在某些情况下，这并不是一个合理的建议（例如，需要下载模型的文档教程时）。
+
+在这些情况下，您可以在 CI 中重新托管文件到 S3，以便快速访问。Committer 可以在 [upload_ci_resource.yml GitHub Actions flow](https://github.com/apache/tvm/actions/workflows/upload_ci_resource.yml) 上使用 `workflow_dispatch` 来上传一个文件，该文件由 S3 中的名称、哈希和路径指定。sha256 必须与文件匹配，否则将无法上传。上传路径由用户定义，可以是任意路径（不允许尾随或前导斜杠），但要小心不要意外地与现有资源发生冲突。上传完成后，您应该发送一个 PR，上传新的 URL 来更新 [request_hook.py](https://github.com/apache/tvm/blob/main/tests/scripts/request_hook/request_hook.py) 中的 `URL_MAP`。
+
 ## 处理整型常量表达式
 
 TVM 中经常需要处理整型常量表达式。在此之前，首先要考虑的是，是否真的有必要获取一个整型常量。如果符号表达式也有效并且逻辑行得通，那么尽可能用符号表达式。所以生成的代码也适用于未知的 shape。

diff --git a/docs/contribute/committer_guide.md b/docs/contribute/committer_guide.md
@@ -34,6 +34,15 @@ sidebar_position: 4
 -   将 PR 标记为已接受状态，并感谢贡献者/reviewer。
 -   merge PR
 
+## 独立项目管理
+
+在参与项目时，每个人都被假定戴上他们的 Apache committer 角色。也就是说，committers 应在项目活动中为项目的最佳利益而行事。从 committers 和您可能担任的其他角色中区分你的角色在是很重要的。
+
+在项目参与的过程中，明确显示您所担任的角色对可能混淆的情况非常有帮助，特别是在您没有表明 committers 身份的情况下。有两个例子：
+
+"[foo] 角色：[担任 foo 且不担任 commiter 时发消息]"。
+"pache TVM 角色：[在担任 committer 时发消息]".
+
 ## 时间管理
 
 committer 可以做很多事情，例如主持讨论、review pull request 和贡献代码。

diff --git a/docs/contribute/pull_request.md b/docs/contribute/pull_request.md
@@ -105,7 +105,7 @@ TVM_ROOT=`pwd`
 必要的依赖：
 
 ``` bash
-pip install --user pytest Cython synr
+pip install --user pytest Cython
 ```
 
 如果希望运行所有的测试：

diff --git a/docs/contribute/release_process.md b/docs/contribute/release_process.md
@@ -48,20 +48,30 @@ svn cp --username $ASF_USERNAME --password "$ASF_PASSWORD" https://dist.apache.o
 
 ## 截取一个候选版本
 
-要截取一个候选版本，首先用选定的版本字符串截取一个分支，例如，
+要截取一个候选版本，首先用选定的版本字符串截取一个分支。分支的名称应该使用基本发行版本号，而不是补丁（patch）号。例如，要为 v0.11.0 截取一个候选版本，分支应该命名为 v0.11，标签为 `v0.11.0.rc0`，一旦截取便推送到对应分子的 HEAD。
 
 ``` bash
-git clone https://github.com/apache/tvm.git
-cd tvm/
-git branch v0.6.0
-git push --set-upstream origin v0.6.0
+	git clone https://github.com/apache/tvm.git
+	cd tvm/
+
+	# 更新版本号
+	# ...
+	git add .
+	git commit -m "Bump version numbers to v0.6.0"
+
+	# 相关版本替换 v0.6
+	git branch v0.6
+	git push --set-upstream origin v0.6
+
+	git tag v0.6.0.rc0
+	git push origin refs/tags/v0.6.0.rc0
 ```
 
 （*确保源代码中的版本号正确。*运行 `python3 version.py` 进行版本更新。）
 
 转到 GitHub 仓库的 "releases" 选项卡，然后单击 "Draft a new release"，
-
--   以 “v1.0.0.rc0” 的形式提供发布标签，其中 0 表示它是第一个候选版本
+-   检查版本号并确保 TVM 可以构建和运行单元测试来验证发行版本
+-   以 “v1.0.0.rc0” 的形式提供发布标签，其中 0 表示它是第一个候选版本。标签必须严格匹配此模式：`v[0-9]+\.[0-9]+\.[0-9]+\.rc[0-9]`
 -   单击 Target 选择提交：branch \> Recent commits \> \$commit_hash
 -   将发行说明初稿复制并粘贴到说明框中
 -   选择 “This is a pre-release”
@@ -104,6 +114,10 @@ gpg --armor --output apache-tvm-src-v0.6.0.rc0.tar.gz.asc --detach-sig apache-tv
 shasum -a 512 apache-tvm-src-v0.6.0.rc0.tar.gz > apache-tvm-src-v0.6.0.rc0.tar.gz.sha512
 ```
 
+## 更新 `main` 上的 TVM 版本
+
+在截取一个发行候选版本后，务必在整个 main 上更新版本号。例如，如果我们发布了 `v0.10.0`，我们希望将代码库中的版本号从 `v0.10.dev0` 提升到 `v0.11.dev0`。如何执行此操作的示例可以在此处找到：https://github.com/apache/tvm/pull/12190。在最后的一个包含开发标签（例如 `v0.11.dev0`）准备发行时立即在 `main` 上的提交标签。此标签是必须的，以便每晚从 main 构建的包具有正确的版本号。
+
 ## 上传候选版本
 
 编辑 GitHub 上的发布页面并上传前面步骤创建的工程。
@@ -120,6 +134,10 @@ svn add tvm-0.6.0-rc0
 svn ci --username $ASF_USERNAME --password "$ASF_PASSWORD" -m "Add RC"
 ```
 
+## 筛选（cherry-pick）
+在截取了一个发行分支后还没被投票之前，发行管理员可以从 main 分支中 cherry-pick 提交。由于 GitHub 保护发行分支，要将这些修复合并到发行分支（例如 `v0.11`），发行管理员必须向发行分支提交一个 PR，并包含被 cherry-pick 的更改。该 PR 应大致与从 `main` 分支提交的原始 PR 相匹配，并附带有关为何 cherry-pick 该提交的额外细节。然后，社区会对这些 PR 进行标准的审查并合并。请注意，针对发行分支的这些 PR 必须 [签名](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits)。
+
+
 ## 对候选版本投票
 
 第一次投票在 Apache TVM 开发者名单（[[email protected]](mailto:[email protected])）上进行。为了获得更多关注，可以创建一个以 “[VOTE]” 开头的 GitHub Issue，它会自动镜像到 dev@。可以查看以前的投票帖子来了解它是如何进行的。电子邮件应遵循以下格式：
@@ -159,6 +177,11 @@ git push --delete origin v0.6.0.rc2
 
 网站仓库位于 [https://github.com/apache/tvm-site](https://github.com/apache/tvm-site)。向下载页面中添加版本工程以及 GPG 签名和 SHA 哈希。
 
+之后，更新 [下载页面](https://tvm.apache.org/download) 提供最新发行版本。如何操作可参考 [此处](https://github.com/apache/tvm-site/pull/38)。
+
 ## 发布公告
 
 向 [[email protected]](mailto:[email protected]) 和 [[email protected]](mailto:[email protected]) 发送公告邮件。公告应包括发布说明和下载页面的链接。
+
+## 发布补丁（Patch）
+发布 patch 应为修复关键错误而被保留。发布 patch 必须经过与正常发行相同的流程，但发行管理员可以酌情选择缩短为期 24 小时的候选版本投票窗口，以确保修复迅速交付。每个修补版本应提升发布基础分支（例如 `v0.11`）上的版本号，并为发布候选版本创建标签（例如 `v0.11.1.rc0`）。