Skip to content

Commit 63dff38

Browse files
voltjiavoltjia
committed
chore: add pull request template
1 parent 5636cec commit 63dff38

1 file changed

Lines changed: 202 additions & 0 deletions

File tree

‎.github/PULL_REQUEST_TEMPLATE.md‎

Lines changed: 202 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,202 @@
1+
<!--
2+
Thanks for contributing to InfiniOps! Please read `CONTRIBUTING.md` before
3+
opening a pull request and fill out every section below. Delete any section
4+
that is genuinely not applicable (and note why), but do not delete the
5+
"Checklist" section — it must be filled in for every PR.
6+
7+
The PR title MUST follow Conventional Commits, e.g.
8+
feat: add fused RMSNorm kernel
9+
fix: correct stride handling for batched matmul
10+
See: https://www.conventionalcommits.org/
11+
-->
12+
13+
## Summary
14+
15+
<!--
16+
A concise description of **what** this PR changes. Prefer bullet points over
17+
prose. Reference files with backtick-fenced paths (e.g. `src/cuda/gemm/blas.h`).
18+
-->
19+
20+
-
21+
-
22+
23+
## Motivation
24+
25+
<!--
26+
Explain **why** this change is needed. Link to any related issue, bug, or
27+
discussion. If this is a performance change, include before/after numbers
28+
(hardware, shape, dtype, and the measurement methodology).
29+
-->
30+
31+
Closes #
32+
33+
## Type of Change
34+
35+
<!-- Tick one or more. The type MUST match the Conventional Commits prefix
36+
in the PR title and the branch name (see `CONTRIBUTING.md` §Branches). -->
37+
38+
- [ ] `feat` — new feature / new operator / new platform
39+
- [ ] `fix` — bug fix
40+
- [ ] `perf` — performance improvement (no behavioral change)
41+
- [ ] `refactor` — code restructuring without behavior change
42+
- [ ] `test` — adding or fixing tests only
43+
- [ ] `docs` — documentation only
44+
- [ ] `build` / `ci` — build system or CI configuration
45+
- [ ] `chore` — tooling, formatting, or other non-code changes
46+
- [ ] Breaking change (requires a `!` in the Conventional Commits prefix or a `BREAKING CHANGE:` footer)
47+
48+
## Platforms Affected
49+
50+
<!-- Tick every backend whose code is touched **or** whose behavior may change. -->
51+
52+
- [ ] CPU (`WITH_CPU`)
53+
- [ ] NVIDIA (`WITH_NVIDIA`)
54+
- [ ] Iluvatar (`WITH_ILUVATAR`)
55+
- [ ] MetaX (`WITH_METAX`)
56+
- [ ] Cambricon (`WITH_CAMBRICON`)
57+
- [ ] Moore (`WITH_MOORE`)
58+
- [ ] Ascend (`WITH_ASCEND`)
59+
- [ ] PyTorch C++ bindings (`WITH_TORCH`)
60+
- [ ] Build system / CMake / CI
61+
- [ ] Python bindings / user-facing API
62+
63+
## Test Results on Supported Platforms
64+
65+
<!--
66+
Per `CONTRIBUTING.md` §Pull Requests #3, you MUST build and test on every
67+
supported platform touched by this PR (or explain why a platform is not
68+
reachable). Paste `pytest` output summaries below (a trimmed tail is fine —
69+
include pass/fail counts, skipped tests, and any warnings).
70+
71+
If a platform was **not** tested, state the reason (e.g. "no hardware
72+
available"). Reviewers may block the PR until coverage is provided or an
73+
explicit owner signs off on a partial run.
74+
-->
75+
76+
| Platform | Built | `pytest` Result | Notes / Hardware |
77+
| ---------- | :---: | --------------- | ---------------- |
78+
| NVIDIA | | | |
79+
| Iluvatar | | | |
80+
| MetaX | | | |
81+
| Cambricon | | | |
82+
| Moore | | | |
83+
| Ascend | | | |
84+
85+
<details>
86+
<summary>Full `pytest` output (optional)</summary>
87+
88+
```text
89+
paste here
90+
```
91+
92+
</details>
93+
94+
## Benchmark / Performance Impact
95+
96+
<!--
97+
Required for `perf` PRs; optional otherwise. Describe the benchmark harness,
98+
shapes, dtypes, hardware, and include baseline vs. new numbers. If the PR is
99+
not performance-sensitive, write "N/A".
100+
-->
101+
102+
## Notes for Reviewers
103+
104+
<!--
105+
Anything reviewers should focus on: subtle invariants, known trade-offs,
106+
follow-up work intentionally left out of scope, etc.
107+
-->
108+
109+
---
110+
111+
## Checklist
112+
113+
> Every contributor **must** verify every item below before requesting
114+
> review. Tick each box only after the check has actually been performed —
115+
> do not tick speculatively. If an item truly does not apply, replace the
116+
> checkbox with `N/A` and briefly explain why in an inline comment.
117+
118+
### Title, Branch, and Commits
119+
120+
- [ ] PR **title** follows [Conventional Commits](https://www.conventionalcommits.org/) (e.g. `feat(nvidia): …`, `fix(cuda/gemm): …`).
121+
- [ ] Branch name follows `<type>/xxx-yyyy-zzzz` where `<type>` matches the PR title's Conventional Commits type and words are joined with hyphens (see `CONTRIBUTING.md` §Branches).
122+
- [ ] Each **commit** message follows Conventional Commits.
123+
- [ ] Small PR is a **single squashable commit**; or, for a large PR, every commit is meaningful, well-formed, and independently reviewable (see `CONTRIBUTING.md` §Pull Requests #1).
124+
- [ ] No stray merge commits from `master` — the branch is rebased cleanly on top of the current `master`.
125+
- [ ] No `fixup!` / `squash!` / `wip` commits remain.
126+
127+
### Scope and Design
128+
129+
- [ ] Changes are **minimal** — nothing unrelated to the stated motivation was added (`CONTRIBUTING.md` §Code/General #1).
130+
- [ ] No dead code, commented-out blocks, debug prints, `printf`/`std::cout`/`print(...)` left behind, or `TODO` without an owner and issue link.
131+
- [ ] No unrelated formatting churn that would obscure the diff.
132+
- [ ] Public API changes (if any) are intentional, documented, and reflected in affected callers/tests.
133+
134+
### General Code Hygiene (applies to all languages)
135+
136+
- [ ] The code is self-explanatory; comments were added **only** where the *why* is non-obvious (`CONTRIBUTING.md` §Code/General #2).
137+
- [ ] Every modified or added file **ends with a single trailing newline** (`CONTRIBUTING.md` §Code/General #3).
138+
- [ ] No trailing whitespace, tab/space mixing, or stray BOMs.
139+
- [ ] Identifiers in comments and error messages are wrapped in backticks (e.g. ``the `seqlens_k` tensor``) (`CONTRIBUTING.md` §Code/General #4).
140+
- [ ] All comments and error messages are in **English** (`CONTRIBUTING.md` §Code/General #5).
141+
- [ ] Comments and error messages are complete sentences — capitalized first letter, terminal punctuation — **unless** the language/framework convention says otherwise (`CONTRIBUTING.md` §Code/General #6; Python #2).
142+
143+
### C++ Specific (if C++ files changed)
144+
145+
- [ ] Code follows the [Google C++ Style Guide](https://google.github.io/styleguide/cppguide.html) strictly.
146+
- [ ] `clang-format` (version **21**, per `.github/workflows/clang-format.yml`) has been run against all modified `.h`, `.cc`, `.cuh`, and `.mlu` files; the diff is clean.
147+
- [ ] `clang-tidy` concerns (per `.clang-tidy`) have been reviewed — no new warnings beyond the existing baseline.
148+
- [ ] Operator parameter order is **inputs first, outputs last**; attributes are between inputs and outputs; naming follows PyTorch → ONNX → CUDA API precedence (`CONTRIBUTING.md` §C++ #2).
149+
- [ ] **No exceptions** are thrown. Error paths use `assert` with messages that include at least `__FILE__`, `__LINE__`, and `__func__` (`CONTRIBUTING.md` §C++ #3).
150+
- [ ] Error and warning message wording follows the [LLVM Coding Standards](https://llvm.org/docs/CodingStandards.html#error-and-warning-messages) (`CONTRIBUTING.md` §C++ #4).
151+
- [ ] Kernel files are named correctly: custom = `kernel` / `kernel_v2` / …; well-known algorithms use the algorithm name; library-based implementations use the library name (`CONTRIBUTING.md` §C++ #5).
152+
- [ ] Kernel and kernel launcher are in **separate files**: launcher `.h`, kernel follows platform conventions (e.g. `.cuh` + `.cu`) even when non-templated (`CONTRIBUTING.md` §C++ #6).
153+
- [ ] Constructor **initializer list order matches member declaration order** (`CONTRIBUTING.md` §C++ #7).
154+
- [ ] Exactly **one blank line** between classes, between classes and functions, and between functions (`CONTRIBUTING.md` §C++ #8).
155+
- [ ] Exactly **one blank line** between members (functions *and* variables) within a class (`CONTRIBUTING.md` §C++ #9).
156+
- [ ] Exactly **one blank line** before and after the contents of a namespace (`CONTRIBUTING.md` §C++ #10).
157+
- [ ] New operators added via `src/base/<op>.h` (inheriting `Operator<Op>`) with platform implementations under `src/<category>/<platform>/` inheriting the base (`CONTRIBUTING.md` §Adding an Operator #1–2).
158+
- [ ] No raw `new`/`delete`; RAII / smart pointers / existing allocators are used.
159+
160+
### Python Specific (if Python files changed)
161+
162+
- [ ] Code is [PEP 8](https://peps.python.org/pep-0008/) compliant; `ruff check` passes cleanly on CI (see `.github/workflows/ruff.yml`).
163+
- [ ] `ruff format --check` passes cleanly — if not, run `ruff format` and commit the result.
164+
- [ ] Comments are complete English sentences, starting with a capital letter and ending with punctuation; Markdown backticks are used for code references (`CONTRIBUTING.md` §Python #1).
165+
- [ ] Framework-specific conventions (e.g. lowercase `pytest.skip` messages without terminal period) are honored where applicable (`CONTRIBUTING.md` §Python #2).
166+
- [ ] **No blank line** between the function signature and the body when there is no docstring or comment (`CONTRIBUTING.md` §Python #3).
167+
- [ ] A blank line is present **before and after** `if`, `for`, and similar control-flow statements (`CONTRIBUTING.md` §Python #4).
168+
- [ ] A blank line appears **before** each `return`, except when it directly follows a control-flow statement (`CONTRIBUTING.md` §Python #5).
169+
- [ ] Docstrings (if any) follow [PEP 257](https://peps.python.org/pep-0257/) (`CONTRIBUTING.md` §Python #6).
170+
- [ ] Type hints are added / kept consistent with the surrounding code.
171+
172+
### Testing
173+
174+
- [ ] `pytest` was run locally on **every supported platform** that this PR can affect, and the results are recorded in the "Test Results" table above (`CONTRIBUTING.md` §Pull Requests #3).
175+
- [ ] For any platform that could not be tested, an explicit reason is given in the table and a reviewer with access has been tagged.
176+
- [ ] New functionality has matching tests under `tests/` following `tests/test_add.py` / `tests/test_gemm.py` patterns (`CONTRIBUTING.md` §Adding an Operator #3).
177+
- [ ] Tests use `pytest.mark.parametrize` correctly: dependent parameters share one decorator (e.g. `@pytest.mark.parametrize("dtype, rtol, atol", …)`), independent parameters use separate decorators ordered by parameter declaration.
178+
- [ ] Where appropriate, `pytest.mark.auto_act_and_assert` is used and the test returns a `Payload` whose `func` and `ref` share the same calling convention.
179+
- [ ] Default `dtype` / `device` parameterization is relied on, or overridden with an explicit `pytest.mark.parametrize` when necessary.
180+
- [ ] Any new test that is flaky under parallelism is marked so, or documented to require `pytest -n 1`.
181+
- [ ] For bug fixes: a regression test has been added that fails on `master` and passes with this PR.
182+
183+
### Build, CI, and Tooling
184+
185+
- [ ] The project builds cleanly from a fresh directory with `pip install .[dev]` on at least one affected platform.
186+
- [ ] `compile_commands.json` still regenerates (CMake option `CMAKE_EXPORT_COMPILE_COMMANDS=ON` in `pyproject.toml` — required by the `code-lint` skill and `clang-tidy -p`).
187+
- [ ] New backends / devices have been added to auto-detection in `CMakeLists.txt` under `if(AUTO_DETECT_DEVICES)` **and** to `if(AUTO_DETECT_BACKENDS)` if applicable.
188+
- [ ] Only one CUDA-like GPU backend is selectable at a time — the existing mutual-exclusion check in `CMakeLists.txt` is not broken.
189+
- [ ] Both CI workflows (`clang-format.yml`, `ruff.yml`) are green locally (or expected to be green on CI).
190+
- [ ] No new runtime dependency was added without updating `pyproject.toml`'s `[project.optional-dependencies]` (or justified in the PR description).
191+
192+
### Documentation
193+
194+
- [ ] `README.md`, `CONTRIBUTING.md`, or inline docs updated when behavior, build flags, or developer workflow changed.
195+
- [ ] New operators, new dispatch helpers, or new public utilities are documented (docstring, header comment, or an addition to `CONTRIBUTING.md` §Some Code Explanations).
196+
- [ ] Any user-visible breaking change is called out explicitly under "Motivation" **and** in the commit/PR title with a `!` or `BREAKING CHANGE:` footer.
197+
198+
### Security and Safety
199+
200+
- [ ] No secrets, access tokens, internal URLs, customer data, or personal hardware identifiers have been committed.
201+
- [ ] Third-party code is license-compatible and attributed.
202+
- [ ] No unsafe pointer arithmetic, uninitialized reads, or missing bounds checks were introduced.

0 commit comments

Comments
 (0)