You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
so anything matching any alias mentioned both owners. The same row exists in the knowledge tree (knowledge/repos/vllm-omni/owners/model_owner.md), which is where the runtime catalog is mirrored from — a fix in one place only would have been undone by the next knowledge sync.
Only the negative claim was applied, because only it is evidenced: across vllm-project/vllm-omni since 2026-05, psv666 authored nothing under qwen2_5_omni* or qwen3_omni*, while amy-why-3459 authored 16 commits under qwen3_omni* and remains the owner — so the qwen3-omni half of the alias list still reaches a real person.
Three tests pinned the two-owner tuple and moved with the data. The added regression test is anchored on a real issue title from the reported set rather than on the entry name, so re-pointing the alias at that handle fails the suite rather than shipping quietly.
What this did not decide
Whether qwen2.5-omni deserves its own entry with its own owner is a real question and commit history cannot answer it — it shows who touched a path, not who is accountable for it. Guessing a name would reproduce this exact bug for someone else. That question is tracked with the rest of the catalog work in #87, which lists eleven further models with no entry at all.
If qwen2.5-omni does have a distinct owner, adding that row is a two-line change in both files.
Activity
tzhouam commentedon Sep 11, 2026
Fixed and deployed. The bot no longer mentions @psv666 on qwen2.5-omni issues.
What was wrong
Routing was doing exactly what the catalog told it to.
model_owners.jsoncarried a singleqwen-omnientry whose alias list spans two models:so anything matching any alias mentioned both owners. The same row exists in the knowledge tree (
knowledge/repos/vllm-omni/owners/model_owner.md), which is where the runtime catalog is mirrored from — a fix in one place only would have been undone by the next knowledge sync.What changed
qwen-omniowners →["amy-why-3459"]Only the negative claim was applied, because only it is evidenced: across vllm-project/vllm-omni since 2026-05, psv666 authored nothing under
qwen2_5_omni*orqwen3_omni*, while amy-why-3459 authored 16 commits underqwen3_omni*and remains the owner — so the qwen3-omni half of the alias list still reaches a real person.Three tests pinned the two-owner tuple and moved with the data. The added regression test is anchored on a real issue title from the reported set rather than on the entry name, so re-pointing the alias at that handle fails the suite rather than shipping quietly.
What this did not decide
Whether qwen2.5-omni deserves its own entry with its own owner is a real question and commit history cannot answer it — it shows who touched a path, not who is accountable for it. Guessing a name would reproduce this exact bug for someone else. That question is tracked with the rest of the catalog work in #87, which lists eleven further models with no entry at all.
If qwen2.5-omni does have a distinct owner, adding that row is a two-line change in both files.
🤖 Generated with Claude Code
https://claude.ai/code/session_01KT4EvUTzzLeq243DG6T1mC