ref(upstream): FULL TREE — Deep-Spark xllm (1470) + ds_vllm csrc/models (703)
Replaces cherry-picked upstream_ref with complete source trees. xllm/ — Iluvatar official C++ inference engine (15MB, 1470 files) Complete: kernels → layers → models → runtime → scheduler → api Excluded: .git, binary images, third_party submodule checkouts ds_vllm/ — Iluvatar official vllm fork (8MB, 703 files) Included: csrc/ (ALL CUDA kernels), fused_moe/, qwen3_5 model, _custom_ops Excluded: tests, benchmarks, docs, examples (not needed for reference) Critical call chains now fully traceable: MoE: moe_topk_softmax_kernels.cuh → ixformer.h → fused_moe.cpp → layer GDN: qwen3_gated_delta_net_base.cpp → qwen3_5_gated_delta_net.cpp Attention: ixformer.h → xllm_paged_attention → attention.cpp
This commit is contained in:
EX Engine
@@ -0,0 +1,30 @@
|
||||
# Backport Flow
|
||||
|
||||
When a released line needs a bugfix, prefer this flow:
|
||||
|
||||
1. land the fix on `main` first unless the user explicitly needs a direct hotfix flow
|
||||
2. cherry-pick or backport the fix to the matching `release/vX.Y.Z` branch
|
||||
3. update release content as needed on that release branch
|
||||
4. create the next patch tag for that release line
|
||||
|
||||
Example shape:
|
||||
|
||||
```bash
|
||||
# land on main first
|
||||
git checkout main
|
||||
git pull --rebase upstream main
|
||||
git checkout -b bugfix/<topic>
|
||||
git commit -m "bugfix: fix <summary>."
|
||||
|
||||
# then backport
|
||||
git checkout release/v0.9.0
|
||||
git pull --rebase upstream release/v0.9.0
|
||||
git cherry-pick <bugfix_commit>
|
||||
git tag v0.9.1
|
||||
```
|
||||
|
||||
## Quick Checklist
|
||||
|
||||
- backport from a commit already landed on `main` when possible
|
||||
- cherry-pick onto the matching `release/vX.Y.Z` branch
|
||||
- use the next semantic patch tag for the release line
|
||||
@@ -0,0 +1,54 @@
|
||||
# Branch Naming
|
||||
|
||||
Use one of these branch shapes:
|
||||
|
||||
```text
|
||||
<type>/<topic>
|
||||
<namespace>/<type>/<topic>
|
||||
preview/<topic>
|
||||
release/vX.Y.Z
|
||||
```
|
||||
|
||||
Recommended lowercase branch types:
|
||||
|
||||
- `feat`: new user-visible capability or feature work
|
||||
- `bugfix`: incorrect behavior, regressions, or hot fixes
|
||||
- `refactor`: structural changes without intended behavior changes
|
||||
- `docs`: documentation-only work when a dedicated branch is useful
|
||||
- `test`: test-only work when separated from product changes
|
||||
- `perf`: runtime or memory improvements
|
||||
- `chore`: repo maintenance that does not fit the other categories
|
||||
- `build`: dependency, CI, packaging, or release tooling changes
|
||||
|
||||
Topic guidelines:
|
||||
|
||||
- use lowercase letters, numbers, and hyphens by default
|
||||
- keep the topic short, specific, and review-friendly
|
||||
- prefer nouns or short noun phrases like `scheduler`, `lm-head-new`, `npu-template`
|
||||
- avoid spaces, uppercase letters, and vague names like `misc`, `temp`, `test-branch`
|
||||
- avoid repeating the type in the topic, such as `feat/feature-x`
|
||||
- use slash-separated namespace prefixes only when the work clearly belongs to a scoped stream
|
||||
|
||||
Scoped branch guidelines:
|
||||
|
||||
- use `<namespace>/<type>/<topic>` for team-, model-, or project-scoped work such as `dsv4/feat/rope-dsv4`
|
||||
- keep the namespace stable and meaningful, not personal or temporary
|
||||
- use `preview/<topic>` only for preview-track work that intentionally aligns with preview branches upstream
|
||||
- reserve `release/vX.Y.Z` for release preparation or release-only changes
|
||||
- avoid direct development on `main` and `release/*` unless the user explicitly asks for it
|
||||
|
||||
Examples:
|
||||
|
||||
- `feat/skills`
|
||||
- `feat/lm_head_new`
|
||||
- `bugfix/scheduler`
|
||||
- `refactor/npu_template`
|
||||
- `preview/glm-5`
|
||||
- `release/v0.9.0`
|
||||
|
||||
Notes for xLLM:
|
||||
|
||||
- `main` is the default development branch
|
||||
- `feat/*`, `bugfix/*`, and `refactor/*` appear in current branch usage and are safe defaults
|
||||
- `preview/*` and `release/*` are long-lived integration branches, not ordinary personal topic branches
|
||||
- both hyphen and underscore appear in existing history, but prefer hyphens for new branch topics unless matching an established naming family
|
||||
@@ -0,0 +1,56 @@
|
||||
# Commit Format
|
||||
|
||||
Use this exact first-line format:
|
||||
|
||||
```text
|
||||
<type>: <subject>
|
||||
```
|
||||
|
||||
Allowed lowercase types:
|
||||
|
||||
- `feat`: add user-visible behavior or a new capability
|
||||
- `bugfix`: correct incorrect behavior or a regression
|
||||
- `docs`: change documentation only
|
||||
- `test`: add or update tests only
|
||||
- `refactor`: improve structure without changing intended behavior
|
||||
- `chore`: repository maintenance that does not fit the other types
|
||||
- `style`: formatting or style-only changes without logic changes
|
||||
- `revert`: revert an earlier commit
|
||||
- `perf`: improve runtime or memory behavior
|
||||
- `model`: change model definitions, checkpoints, prompts, or inference behavior
|
||||
- `build`: change build, release, or dependency wiring
|
||||
- `release`: change release versioning, release notes, or release-only metadata
|
||||
|
||||
Subject guidelines:
|
||||
|
||||
- use lowercase letters by default
|
||||
- include at least 4 words
|
||||
- end with a period
|
||||
- start with a verb like `add`, `fix`, `remove`, `refactor`, `document`
|
||||
- keep it specific enough that a reviewer understands the main change
|
||||
- avoid filler like `update`, `misc`, `stuff`, `changes`
|
||||
- describe the effect or intent, not a mechanical file list
|
||||
|
||||
Body guidelines:
|
||||
|
||||
- add a body only when the title alone is not enough
|
||||
- use short bullets for secondary details or important context
|
||||
- mention follow-up work, migration steps, or compatibility impact when relevant
|
||||
- if confidence is low because the diff is partial or noisy, say that explicitly
|
||||
|
||||
Observed xLLM-style examples:
|
||||
|
||||
- `feat: add rope_in_place tilelang kernel for npu device. (#964)`
|
||||
- `bugfix: align rec initialization flags with options. (#1142)`
|
||||
- `docs: update the document to align them with the latest code. (#1113)`
|
||||
- `refactor: extract multi-modal input processors to processors dir. (#1022)`
|
||||
- `perf: reserve vector capacity before batch push_back. (#1089)`
|
||||
- `release: update xllm release version to v0.9.0. (#1124)`
|
||||
- `feat: support qwen3.5/qwen3.5-moe mtp draft model for speculative decoding[3/N]. (#1119)`
|
||||
|
||||
Notes for xLLM:
|
||||
|
||||
- `bugfix:` appears more often than `fix:` in current history and should be the default bug-repair prefix
|
||||
- `fix:` exists in a few historical commits but is less consistent than `bugfix:`
|
||||
- PR-number suffixes like `(#1142)` are common in merged history but are optional unless the user explicitly wants them
|
||||
- staged series markers like `[1/N]` or `[3/N]` appear when a change is intentionally split across multiple commits
|
||||
@@ -0,0 +1,33 @@
|
||||
# Development Flow
|
||||
|
||||
Follow this sequence unless the user asks for a different workflow:
|
||||
|
||||
1. fork the upstream repository
|
||||
2. sync local `main` with `upstream/main`
|
||||
3. create a focused topic branch from `main`
|
||||
4. implement the change
|
||||
5. run formatting and the narrowest relevant validation
|
||||
6. commit in clear English
|
||||
7. push to the fork
|
||||
8. open a PR to upstream `main`
|
||||
|
||||
Example commands:
|
||||
|
||||
```bash
|
||||
git fetch upstream
|
||||
git checkout main
|
||||
git pull --rebase upstream main
|
||||
git checkout -b feat/<topic>
|
||||
|
||||
# after development
|
||||
git add <files>
|
||||
git commit -m "feat: add <change summary>."
|
||||
git push origin feat/<topic>
|
||||
```
|
||||
|
||||
## Quick Checklist
|
||||
|
||||
- branch from `main` unless this is a release or backport task
|
||||
- keep the branch focused on one change
|
||||
- run the narrowest relevant validation before commit
|
||||
- push to your fork before opening the PR
|
||||
@@ -0,0 +1,28 @@
|
||||
# PR And Review
|
||||
|
||||
## Pull Request Guidance
|
||||
|
||||
The public repo guidance is lightweight:
|
||||
|
||||
- `README.md` and `CONTRIBUTING.md` ask contributors to fork, create a branch, and send a pull request
|
||||
- keep PRs focused and easy to review, even though the public docs do not publish a hard line-count limit
|
||||
- write commit messages and PR descriptions in clear English
|
||||
- avoid unnecessary merge noise in branch history; prefer a clean linear history when practical
|
||||
|
||||
## Target Branch
|
||||
|
||||
- use `main` unless this is explicitly a release or backport task
|
||||
|
||||
## Review Expectations
|
||||
|
||||
Use `.github/CODEOWNERS` as the visible review signal:
|
||||
|
||||
- changes under `/xllm/` have listed code owners
|
||||
- expect owner review or owner attention for those paths
|
||||
- if the user asks who should review a change under `/xllm/`, check `CODEOWNERS`
|
||||
|
||||
## Quick Checklist
|
||||
|
||||
- PR target is `main` unless this is a backport or release task
|
||||
- PR is focused and clearly described
|
||||
- review expectations are checked through `CODEOWNERS`
|
||||
@@ -0,0 +1,15 @@
|
||||
# Release Layout
|
||||
|
||||
Observed public release layout:
|
||||
|
||||
- release branches use `release/vX.Y.Z`
|
||||
- observed release branches include `release/v0.6.0`, `release/v0.7.0`, `release/v0.8.0`, and `release/v0.9.0`
|
||||
- release notes are tracked in `RELEASE.md`
|
||||
- public tags use semantic version tags such as `v0.9.0`
|
||||
- patch tags use normal patch versions such as `v0.7.1` and `v0.7.2`, not `-rcN`
|
||||
|
||||
## Naming Guardrails
|
||||
|
||||
- do not switch to `release_0.1.0` branches unless the user explicitly wants an older internal workflow
|
||||
- do not assume `v0.1.0-rc0` style tags unless the user explicitly asks for them
|
||||
- prefer the next semantic patch tag for bugfix releases
|
||||
@@ -0,0 +1,29 @@
|
||||
# Source Of Truth
|
||||
|
||||
Use these repo files first when the user asks for xLLM-specific Git guidance:
|
||||
|
||||
- `README.md`
|
||||
- `CONTRIBUTING.md`
|
||||
- `RELEASE.md`
|
||||
- `.github/workflows/check_format.yml`
|
||||
- `.pre-commit-config.yaml`
|
||||
- `.github/CODEOWNERS`
|
||||
|
||||
Guidance priority:
|
||||
|
||||
1. direct user request
|
||||
2. current repo files and branch reality
|
||||
3. visible remote repo conventions
|
||||
4. older internal notes or remembered habits
|
||||
|
||||
When repo docs, local repo state, and user wording disagree:
|
||||
|
||||
- say the conflict explicitly
|
||||
- prefer the most concrete source available
|
||||
- avoid inventing rules that are not visible in the public repo
|
||||
|
||||
Common examples of rules you should not assume without evidence:
|
||||
|
||||
- rebase-only or squash-only merge requirements
|
||||
- mandatory reviewer counts beyond what `CODEOWNERS` implies
|
||||
- old naming patterns such as `features/*`, `release_0.1.0`, or `v0.1.0-rc0`
|
||||
Reference in New Issue
Block a user