Skip to content

Issue forms: bug report, model request, feature request; no blank issues - #155

Merged
bong-water-water-bong merged 1 commit into
mainfrom
issue-templates
Sep 26, 2026
Merged

bong-water-water-bong merged 1 commit into
mainfrom
issue-templates

Conversation

@bong-water-water-bong

Copy link
Copy Markdown
Collaborator

Adds issue forms under .github/ISSUE_TEMPLATE/:

  • Bug report (bug): what happened, the exact command, the device (dropdown of every --device), the model and where it came from, 1bit version, hardware and OS, and the output. It also asks whether you searched existing issues.
  • Model request (model request, a new label): Hugging Face link, architecture, the devices wanted, and what was tried. It points at the model registry (https://1bit.gg/registry.html) first.
  • Feature request (enhancement): for small changes only. Larger ones (backends, devices, dependencies, formats, APIs) go to an RFC, per CONTRIBUTING.md.
  • config.yml: blank issues are off. The contact links go to Q&A in Discussions, the RFCs category, a private security advisory, and the Discord.

Each form carries the Apache notice. The YAML parses, and tools/copyright.py --check passes.

🤖 Generated with Claude Code

Bug reports ask for the command, device, model, 1bit version, hardware and
output. Questions go to Q&A, larger changes to an RFC and security reports
to a private advisory (config.yml contact links).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 1 🔵⚪⚪⚪⚪
🧪 No relevant tests
🔒 No security concerns identified
⚡ Recommended focus areas for review

Missing Input Validation

The 'command' field in the bug report form does not validate the command format or check for potentially dangerous inputs. While the render: shell attribute helps with display, it does not prevent injection of malicious commands or unintended behavior if the command is executed or parsed by the issue triage process.

id: command
attributes:
  label: Command
  description: The exact command, e.g. `1bit serve -m <model> --device hrx`.
  render: shell
validations:
  required: true
Ambiguous Device Selection

The 'device' dropdown in the model request form allows multiple selections (multiple: true) but does not enforce that at least one device is selected. This could lead to incomplete or unactionable requests if the user fails to select any device.

- type: dropdown
  id: device
  attributes:
    label: Device you want it on
    multiple: true
    options: [npu, vulkan, hrx, rocm, zinc, ds4, mlx, onnx, any]
  validations:
    required: true

@bong-water-water-bong
bong-water-water-bong merged commit 524adeb into main Sep 26, 2026
9 checks passed
@bong-water-water-bong
bong-water-water-bong deleted the issue-templates branch September 26, 2026 17:52
bong-water-water-bong pushed a commit that referenced this pull request Oct 30, 2026
…epSeek-V4.1-Flash, GET_ROWS bound)

third_party/llama.cpp: `d8d2f5b39f22` -> `5e6388a5a852` (1bit-MONSTER/llama.cpp 1bit/hrx-vulkan-patched).
third_party/hrx-system stays at `82804197bcbe` (the commit config/hrx-long-prompt-validated-pin.config names).

Fork commits new to the engine:

- `fe04824` ggml-hrx: an env-gated host-gap profiler (engine #572) (#154)
- `b8861a9` kv: verify the zero padding of the KV cache, and repair it (engine #528) (#155)
- `9e8453a` model: DeepSeek-V4.1-Flash (deepseek41) port of upstream #31086 + #31300 (#156)
- `f61f290` dsv41: drop the dead llm_arch_supports_mixed_batch definition (#157)
- `01d7df4` dsv41: the deepseek41 and DSpark graphs never expanded their output (#158)
- `5e6388a` ggml-hrx: GET_ROWS for a table over 262208 rows (engine #572) (#159)

44 files, +4,289/-209: a new model architecture (deepseek41), the KV zero-padding repair, the
GET_ROWS row/byte bound with its matcher, the host-gap profiler, and their tests
(test-backend-ops cases, test-kv-zero, test-llama-archs).
bong-water-water-bong added a commit that referenced this pull request Oct 31, 2026
* Bump HRX: llama.cpp 5e6388a5a (host-gap profiler, KV zero padding, DeepSeek-V4.1-Flash, GET_ROWS bound)

third_party/llama.cpp: `d8d2f5b39f22` -> `5e6388a5a852` (1bit-MONSTER/llama.cpp 1bit/hrx-vulkan-patched).
third_party/hrx-system stays at `82804197bcbe` (the commit config/hrx-long-prompt-validated-pin.config names).

Fork commits new to the engine:

- `fe04824` ggml-hrx: an env-gated host-gap profiler (engine #572) (#154)
- `b8861a9` kv: verify the zero padding of the KV cache, and repair it (engine #528) (#155)
- `9e8453a` model: DeepSeek-V4.1-Flash (deepseek41) port of upstream #31086 + #31300 (#156)
- `f61f290` dsv41: drop the dead llm_arch_supports_mixed_batch definition (#157)
- `01d7df4` dsv41: the deepseek41 and DSpark graphs never expanded their output (#158)
- `5e6388a` ggml-hrx: GET_ROWS for a table over 262208 rows (engine #572) (#159)

44 files, +4,289/-209: a new model architecture (deepseek41), the KV zero-padding repair, the
GET_ROWS row/byte bound with its matcher, the host-gap profiler, and their tests
(test-backend-ops cases, test-kv-zero, test-llama-archs).

* registry+census: derive the new pin's data (DeepSeek-V4.1-Flash now maps)

Two generated/reviewed data sets derive from the pinned backends, and the pin move has to carry
both or the tree's own checks go red at the new pin. Reported by CI on the bump head; both
reproduced locally first.

**registry (ctest registry_pins):**
"llama.cpp (hrx) recorded at d8d2f5b39, pinned at 5e6388a5a" - `tools/registry_build.py`
regenerated `registry/architectures.json` at the new pin: source string, plus
`DeepseekV41ForCausalLM -> deepseek41, hrx`, counts hrx 293 -> 294. That map is legitimate at
`5e6388a5a`: `conversion/__init__.py` maps the class, `src/llama-arch.cpp` registers
`LLM_ARCH_DEEPSEEK41`, and `src/models/deepseek41.cpp` implements hparams/tensors/graph/engram
(fork #156 = upstream #31086 + #31300). The class had been reviewed as *not an alias* of
`deepseek4`, so `--check-gaps` correctly refused a silent map: `registry/significant.json` now
carries a `mapped_ok` reason naming the commit and the port, its `family` text no longer claims
the pinned path runs "neither", and `docs/arch-gaps.md` gets the dated note (the "not mapped"
recheck it quotes was against `6b397ee9`, before the port). `tests/registry_gaps_test.py`'s
committed-state invariant changes from "no reviewed class is a key in the registry" to "every
reviewed class the registry maps carries a non-vacuous `mapped_ok`", with the CLI case driven by
a class that genuinely has no reason.

**census (ctest census_watch):** the watcher's test listed `DeepseekV41ForCausalLM` among the
classes reviewed *report-only* (#522: "needs real support: engram + candidate blocks"), which is
exactly what the new pin changes. The entry moves out of that table and becomes an assertion of
the opposite: the same model is now COVERED, exit 0, with no `significant` alert and no
`reviewed_report` line - alerting on a class the engine supports is the false alarm this watcher
exists to avoid.

`registry/census.json` itself needs no regeneration: it is the Hugging Face snapshot
(`date`/`coverage`/`raw`, written by `tools/census.py`), not pin-derived.

Green locally at this pin: `registry_build.py --check-pins`, `--check-gaps`,
`tests/registry_gaps_test.py`, `tests/census_watch_test.py`.

---------

Co-authored-by: bong-water-water-bong <bong-water-water-bong@1bit.gg>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant