From ac6512ed86cb6ad15a7bede4bc34aef494d2c9d5 Mon Sep 17 00:00:00 2001 From: Beckylu <648245013@qq.com> Date: Wed, 29 Jul 2026 17:04:18 +0800 Subject: [PATCH] docs: use one branch for both PR stages --- docs/summer-camp/README.en.md | 54 +++++++++++++++++--------------- docs/summer-camp/README.zh-CN.md | 54 +++++++++++++++++--------------- 2 files changed, 58 insertions(+), 50 deletions(-) diff --git a/docs/summer-camp/README.en.md b/docs/summer-camp/README.en.md index 6ff1e91d..b1ad712b 100644 --- a/docs/summer-camp/README.en.md +++ b/docs/summer-camp/README.en.md @@ -229,31 +229,9 @@ from your own implementation. ## 3. Build the Trust Chain with Two PRs -This section defines the responsibilities and order of the two PRs: PR A establishes the specification, while PR B supplies the implementation, tests, and performance evidence. Both PRs must link the operator-claim Issue. See Section 7 for submission formats and checks. +This section defines the responsibilities and order of the two PRs: PR A establishes the specification, while PR B supplies the implementation, tests, and performance evidence. PR A and PR B use the same `feat/` branch, and both must link the team's operator-claim Issue. See Section 7 for submission formats and checks. -### PR A: Manifest - -PR A defines the operator interface, dtypes, shape rules, workloads, and Roofline formulas before implementation. It is the shared contract for the implementation, tests, and Benchmark. - -Create `manifest/` from `summer-camp-2026`: - -```bash -git switch summer-camp-2026 -git pull --ff-only -git switch -c manifest/ -``` - -Submit only: - -- the new operator entry in `tileops/manifest/.yaml`; create a new Manifest file only when no existing family is appropriate; -- Manifest validation or necessary contract tests; -- an explanation of inputs/outputs, shapes, dtypes, workloads, and Roofline formulas. - -A new Manifest must start with `status: spec-only`. PR A requires a fast review by a teaching assistant or maintainer and may be merged after Manifest validation passes. PR A does not review the Kernel, performance, or C500 data. - -### PR B: Implementation - -After PR A is merged, create `feat/` from the latest `summer-camp-2026`: +Create the development branch from the latest `summer-camp-2026`: ```bash git switch summer-camp-2026 @@ -261,7 +239,31 @@ git pull --ff-only git switch -c feat/ ``` -Submit: +### PR A: Manifest + +PR A defines the operator interface, dtypes, shape rules, workloads, and Roofline formulas before implementation. It is the shared contract for the implementation, tests, and Benchmark. + +In the first stage, submit only: + +- the new operator entry in `tileops/manifest/.yaml`; create a new Manifest file only when no existing family is appropriate; +- Manifest validation or necessary contract tests; +- an explanation of inputs/outputs, shapes, dtypes, workloads, and Roofline formulas. + +A new Manifest must start with `status: spec-only`. PR A requires a fast review by a teaching assistant or maintainer and may be merged after Manifest validation passes. PR A does not review the Op, Kernel, performance, or C500 data. + +Do not commit implementation code to this branch before PR A is merged. + +### PR B: Implementation + +After PR A is merged, continue using the original `feat/` branch and first synchronize it with the latest target branch: + +```bash +git switch feat/ +git fetch origin +git merge origin/summer-camp-2026 +``` + +After synchronization, submit: - a stateless Op under `tileops/ops/`; - a TileLang Kernel under `tileops/kernels/`; @@ -269,6 +271,8 @@ Submit: - an independent baseline Benchmark under `benchmarks/ops/`; - only the Manifest status, provenance, and workload fields that may be updated with the implementation. +After completing the implementation, tests, and C500 performance validation, create PR B from the same branch. + Do not include unrelated refactoring, dependency upgrades, or multiple operators in one PR. ## 4. Migration Requirements diff --git a/docs/summer-camp/README.zh-CN.md b/docs/summer-camp/README.zh-CN.md index 6c23014d..f66fa47c 100644 --- a/docs/summer-camp/README.zh-CN.md +++ b/docs/summer-camp/README.zh-CN.md @@ -219,31 +219,9 @@ subprocess，做 Benchmark 时如遇无输出的 `exit 137`，优先怀疑这个 ## 3. 使用两个 PR 建立信任链 -本节说明两个 PR 的职责和先后关系：PR A 先确定规范，PR B 再完成实现、测试和性能验收；两个 PR 均须链接算子认领 Issue。具体提交格式和检查命令见第 7 节。 +本节说明两个 PR 的职责和先后关系：PR A 先确定规范，PR B 再完成实现、测试和性能验收。PR A 和 PR B 使用同一个 `feat/` 分支，并均须链接本组的算子认领 Issue。具体提交格式和检查命令见第 7 节。 -### PR A：Manifest - -PR A 用于在实现前确定算子的接口、数据类型、形状规则、工作负载和 Roofline 公式，作为后续实现、测试与 Benchmark 的统一契约。 - -从 `summer-camp-2026` 创建 `manifest/`： - -```bash -git switch summer-camp-2026 -git pull --ff-only -git switch -c manifest/ -``` - -只提交： - -- 在 `tileops/manifest/.yaml` 中新增对应算子；仅在没有合适 family 时创建新的 Manifest 文件； -- Manifest 校验或必要的契约测试； -- 对输入输出、shape、dtype、工作负载和 Roofline 公式的说明。 - -新 Manifest 的初始状态必须是 `spec-only`。PR A 必须经过助教或维护者的快速 Review，并在 Manifest 校验通过后合入。PR A 不审核 Kernel、性能或 C500 数据。 - -### PR B：实现 - -PR A 合入后，从最新的 `summer-camp-2026` 创建 `feat/`： +从最新的 `summer-camp-2026` 创建开发分支： ```bash git switch summer-camp-2026 @@ -251,7 +229,31 @@ git pull --ff-only git switch -c feat/ ``` -提交： +### PR A：Manifest + +PR A 用于在实现前确定算子的接口、数据类型、形状规则、工作负载和 Roofline 公式，作为后续实现、测试与 Benchmark 的统一契约。 + +第一阶段只提交： + +- 在 `tileops/manifest/.yaml` 中新增对应算子；仅在没有合适 family 时创建新的 Manifest 文件； +- Manifest 校验或必要的契约测试； +- 对输入输出、shape、dtype、工作负载和 Roofline 公式的说明。 + +新 Manifest 的初始状态必须是 `spec-only`。PR A 必须经过助教或维护者的快速 Review，并在 Manifest 校验通过后合入。PR A 不审核 Op、Kernel、性能或 C500 数据。 + +PR A 合入前，不得在该分支提交实现代码。 + +### PR B：实现 + +PR A 合入后，继续使用原来的 `feat/` 分支，并先同步最新的目标分支： + +```bash +git switch feat/ +git fetch origin +git merge origin/summer-camp-2026 +``` + +同步完成后提交： - `tileops/ops/` 下的无状态 Op； - `tileops/kernels/` 下的 TileLang Kernel； @@ -259,6 +261,8 @@ git switch -c feat/ - `benchmarks/ops/` 下的独立基线 Benchmark； - Manifest 中允许随实现更新的状态、来源和工作负载字段。 +完成实现、测试和 C500 性能验证后，再从同一分支创建 PR B。 + 不要把无关重构、依赖升级或多个算子放进同一个 PR。 ## 4. 迁移要求