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
49
upstream_ref/xllm/.agents/skills/git-workflow/SKILL.md
Normal file
49
upstream_ref/xllm/.agents/skills/git-workflow/SKILL.md
Normal file
@@ -0,0 +1,49 @@
|
||||
---
|
||||
name: git-workflow
|
||||
description: Use when the task involves Git operations for the public xLLM repository, including choosing branch or tag names, preparing commits and pull requests, backporting fixes, checking repo-specific review expectations, or drafting commit messages from actual diffs.
|
||||
---
|
||||
|
||||
# Git Workflow
|
||||
|
||||
Use xLLM repo reality, not generic Git habits.
|
||||
|
||||
## Reference Map
|
||||
|
||||
Load only the file that matches the user's immediate Git task.
|
||||
|
||||
| File | What it is for | When to load it |
|
||||
| --- | --- | --- |
|
||||
| `references/source-of-truth.md` | Repo-specific source priority and canonical files to consult | Load first when repo docs, local state, and user wording may disagree |
|
||||
| `references/branch-naming.md` | Branch naming patterns and default branch conventions | Load when the user asks how to name a branch or which branch to branch from |
|
||||
| `references/development-flow.md` | Day-to-day fork, sync, branch, validate, and push flow | Load when the user asks for normal development steps from local change to push |
|
||||
| `references/pr-review.md` | PR targeting, PR scope, and review expectations | Load when the task is about opening a PR, choosing the target branch, or deciding who should review |
|
||||
| `references/release-layout.md` | Release branch and tag shapes used by xLLM | Load when the task mentions release branches, release tags, or patch version naming |
|
||||
| `references/backport-flow.md` | Preferred backport and hotfix flow for released lines | Load when the task mentions cherry-picks, hotfixes, or fixing an already released branch |
|
||||
| `references/commit-format.md` | Commit title/body conventions and xLLM-style examples | Load when the user asks for a commit message, commit style guidance, or message cleanup |
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Decide which subtask the user actually needs.
|
||||
2. Read `references/source-of-truth.md` when you need repo-specific confirmation.
|
||||
3. Then load only the most relevant task file from the table above.
|
||||
4. For commit message drafting, run `bash scripts/collect_git_context.sh [--staged|--all|--unstaged]` before writing the final message.
|
||||
5. Draft commit messages from the actual diff, not from filenames alone.
|
||||
6. If one diff mixes unrelated concerns, recommend splitting the commit instead of forcing one vague summary.
|
||||
7. Default PR targets to `main` unless the task is clearly a release or backport flow.
|
||||
8. For released lines, prefer landing on `main` first and then backporting unless the user explicitly wants a direct hotfix flow.
|
||||
|
||||
## Output
|
||||
|
||||
Return the smallest useful answer for the user's Git task:
|
||||
|
||||
- workflow questions: concrete branch, tag, PR, or backport steps
|
||||
- commit message requests: `<type>: <subject>` plus an optional short bullet body
|
||||
- repo-convention questions: current xLLM-specific guidance, not generic Git advice
|
||||
|
||||
## Quick Checks
|
||||
|
||||
- branch names match xLLM style such as `feat/<topic>`, `bugfix/<topic>`, or `release/vX.Y.Z`
|
||||
- PR target is `main` unless this is a release or backport task
|
||||
- commit title matches the dominant change in the diff
|
||||
- release tags use semantic versions such as `v0.9.0` or `v0.9.1`
|
||||
- owner-review expectations come from `.github/CODEOWNERS` when relevant
|
||||
@@ -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`
|
||||
@@ -0,0 +1,104 @@
|
||||
#!/usr/bin/env bash
|
||||
|
||||
set -euo pipefail
|
||||
|
||||
mode="auto"
|
||||
|
||||
if [[ $# -gt 1 ]]; then
|
||||
echo "usage: $0 [--staged|--all|--unstaged]" >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
if [[ $# -eq 1 ]]; then
|
||||
case "$1" in
|
||||
--staged)
|
||||
mode="staged"
|
||||
;;
|
||||
--all)
|
||||
mode="all"
|
||||
;;
|
||||
--unstaged)
|
||||
mode="unstaged"
|
||||
;;
|
||||
*)
|
||||
echo "unknown option: $1" >&2
|
||||
echo "usage: $0 [--staged|--all|--unstaged]" >&2
|
||||
exit 1
|
||||
;;
|
||||
esac
|
||||
fi
|
||||
|
||||
if ! git rev-parse --show-toplevel >/dev/null 2>&1; then
|
||||
echo "not inside a git repository" >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
repo_root="$(git rev-parse --show-toplevel)"
|
||||
cd "$repo_root"
|
||||
|
||||
staged_count="$(git diff --cached --name-only | wc -l | tr -d ' ')"
|
||||
untracked_files="$(git ls-files --others --exclude-standard)"
|
||||
|
||||
if [[ "$mode" == "auto" ]]; then
|
||||
if [[ "$staged_count" != "0" ]]; then
|
||||
mode="staged"
|
||||
else
|
||||
mode="all"
|
||||
fi
|
||||
fi
|
||||
|
||||
case "$mode" in
|
||||
staged)
|
||||
status_cmd=(git diff --cached --name-status)
|
||||
stat_cmd=(git diff --cached --stat)
|
||||
patch_cmd=(git diff --cached --unified=1 --no-color)
|
||||
headline="staged changes"
|
||||
;;
|
||||
unstaged)
|
||||
status_cmd=(git diff --name-status)
|
||||
stat_cmd=(git diff --stat)
|
||||
patch_cmd=(git diff --unified=1 --no-color)
|
||||
headline="unstaged changes"
|
||||
;;
|
||||
all)
|
||||
headline="all local changes"
|
||||
;;
|
||||
*)
|
||||
echo "invalid mode: $mode" >&2
|
||||
exit 1
|
||||
;;
|
||||
esac
|
||||
|
||||
echo "repo: $repo_root"
|
||||
echo "branch: $(git branch --show-current)"
|
||||
echo "scope: $headline"
|
||||
echo
|
||||
echo "status:"
|
||||
git status --short
|
||||
echo
|
||||
|
||||
if [[ -n "$untracked_files" ]]; then
|
||||
echo "untracked files:"
|
||||
printf '%s\n' "$untracked_files"
|
||||
echo
|
||||
fi
|
||||
|
||||
if [[ "$mode" == "all" ]]; then
|
||||
echo "changed files:"
|
||||
git diff HEAD --name-status
|
||||
echo
|
||||
echo "diff stat:"
|
||||
git diff HEAD --stat
|
||||
echo
|
||||
echo "patch excerpt:"
|
||||
git diff HEAD --unified=1 --no-color | sed -n '1,400p'
|
||||
else
|
||||
echo "changed files:"
|
||||
"${status_cmd[@]}"
|
||||
echo
|
||||
echo "diff stat:"
|
||||
"${stat_cmd[@]}"
|
||||
echo
|
||||
echo "patch excerpt:"
|
||||
"${patch_cmd[@]}" | sed -n '1,400p'
|
||||
fi
|
||||
Reference in New Issue
Block a user