Open Source · Issues

問題發現、修復與同儕審查

GitHub merged PR 之外的貢獻：我回報又自己修好並合併的上游 bug、我回報由他人／社群修復的問題、別人回報而由我修好的 issue、確認中或待上游處理的 active reports，以及學術同儕審查（JOSS、IEEE）。代表工作在 Overview、完整帳本在 Ledger。

Peer Review · Issues · Cross-Platform

學術同儕審查 · 重點 Issues · 跨平台貢獻

GitHub merged PR 之外的貢獻，分五類：A 學術同儕審查、B 自己回報又自己修好並合併的上游 bug 與自提並實作的功能（端到端，共 97 筆 Found & Fixed）、C 我回報但由他人修復或仍在審查中、D 他人回報而由我修復並合併（63 則）、E 我審他人的 PR（78 筆）。

A · 學術同儕審查

IEEE WF-PST 2026 — Technical Program Reviewer 學術同儕審查 · 2026 IEEE World Forum on Public Safety Technology（IEEE 公共安全科技世界論壇）· 受 PC member 邀請審查投稿稿件（accepted papers → IEEE Xplore）
JOSS Peer Review — Metaxy（anam-org/metaxy） Journal of Open Source Software 指派我擔任一件投稿的正式審查人：Metaxy（anam-org/metaxy，GPU 加速 ML 管線的 record-level 特徵 metadata 管理）。JOSS 對同一份稿分兩階段送審：#10141 pre-review、#10449 review。我把審查意見依 JOSS 的評審面向拆成三條、直接開進 metaxy 自己的 repo 追蹤：論文呈現與 metadata（#1191）、宣稱佐證與軟體設計（#1192）、參考文獻封存 DOI（#1193）。

B · 自報自修並合併 — 端到端（共 97 筆 Found & Fixed）

cert-manager/cert-manager — Issue #9126 Issue（Bug · CNCF Graduated）· CertificateRequest 有 failureTime 卻沒有 Ready condition 時，發證會靜默卡住：issuing controller 與 request manager 往下走的守衛都要求 Ready condition，這種請求既不算失敗、不退避，也不會被換掉 · 2026-08-12 回報，源自 wallrj 在 #9118 審查中注意到、建議另開 · pujitha24 的 #9128 先讓卡住的狀態看得見（2026-09-04 合併），wallrj 以卡住本身仍在為由重新開啟 · 自行修復 → PR #9287 merged（把這種請求比照 Ready=False/Failed 放寬三個既有守衛，+967/-29、8 檔，含整合測試）· 2026-09-29 由 wallrj lgtm、合併並關閉
zephyrproject-rtos/zephyr — Issue #115251 Issue（Bug · MIPI DBI · Linux Foundation 直屬）· cs_is_gpio 由全控制器層級的檢查決定，旁邊的 GPIO spec 卻按裝置自己的 reg 索引，於是 reg 超出控制器 cs-gpios 長度的裝置同時拿到「有 GPIO CS」與一個空的 spec：兩半在兩次修正之間走岔，先是巨集把 DT_BUS() 烘死而 MIPI DBI 裝置的 DT_BUS() 指向 MIPI DBI 節點不是 SPI 控制器，後來只修掉述詞那一半 · 自行修復 → PR #115254 merged（+38/-4、3 檔，含 build_all overlay 與測試）· 2026-08-04 回報、2026-09-29 由 nashif 合併並關閉
zephyrproject-rtos/zephyr — Issue #115726 Issue（Bug · ESP32 DMA · Linux Foundation 直屬）· stop 沒有清掉鎖存的 raw interrupt status，下一次 start 會把上一筆傳輸的 callback 送出去：dma_esp32_stop() 返回時留著鎖存的中斷狀態，重新啟動之後硬體看到的是上一筆傳輸留下的位元，回呼於是在還沒有資料的時候先發一次 · 2026-08-09 回報 · 自行修復 → PR #113311 merged（同一支讓 dma_esp32_stop() 在返回前 reset channel 並清掉它的中斷狀態，2026-09-17 合併，+119/-17）· 2026-09-28 自行以 completed 關閉，並在 issue 上寫明修在哪一支、哪一個 commit
Gthulhu/Gthulhu — Issue #150 Issue（Cleanup · eBPF 排程 · 非 CNCF）· decisionmaker/service.go 四處小毛病，寫成給新手的 issue：getProcessInfo 以 fmt.Sprintf("/%s/%d/comm") 組路徑，預設 rootDir = "/proc" 時變成 //proc/…，今天只是靠 Linux 折疊雙斜線才沒事、傳相對路徑就壞（同檔的 FindPodInfoFrom 寫法是對的）；package 層自訂的 max 把 Go 1.21 的內建遮蔽掉；scanner.Err() 讀了就丟；nodePolicyMerkleRoot 寫入卻沒有人讀。四則都不需要 sched_ext 或 BPF 知識，附驗收條件 · 2026-09-20 回報 · 自行修復 → PR #149 merged（同一支把 #135 的整理做完：slices.SortFunc、for range 50、兩段註解改寫成講為什麼，+12/-15）· 2026-09-27 以 completed 關閉
open-telemetry/opentelemetry-cpp — Issue #4396 Issue（Bug · curl HTTP client · CNCF）· 同一個 session 再送一次請求，會刪掉那個還在執行 Cleanup() 的 HttpOperation：Session::SendRequest() 以 unique_ptr::reset 換掉 session 擁有的 operation，而回應的 callback 正是從那個 operation 裡被呼叫的（Cleanup() 取走 callback、在 this 還活著時執行），所以從 OnResponse 裡再送一次就把兩層之外的物件刪掉，回程還要再讀它一次；ASan 報 heap-use-after-free · 2026-08-10 回報 · 自行修復 → PR #4431 merged（一個 session 只送一個請求，第二次回報 CreateFailed；+125/-0、4 檔，owent approve、marcalff 合併）· 2026-09-24 以 completed 關閉
k8snetworkplumbingwg/dra-driver-sriov — Issue #170 Issue（Bug · DRA · Network Plumbing WG）· PodManager.DeleteClaim 刪掉整個 pod 條目，於是同一個 pod 的其他 claim 再也 unprepare 不到：kubelet 一個 claim 一個 claim 地 unprepare，兩個 claim 的 pod 第一次呼叫就把第二個清出 store，後者的 unprepareResourceClaim 找不到就回 nil，VF 沒被 unprepare、driver binding 沒還原、CDI spec 與 device-info 檔留在原地。在 kcli 虛擬叢集重現：pod 消失後 /var/run/cdi 還留著第二個 claim 的 spec · 2026-09-16 回報 · 自行修復 → PR #169 merged（只刪該 claim，並在 checkpoint 寫失敗時回滾記憶體內的變更；+208/-22、4 檔，SchSeba 合併）· 2026-09-24 以 completed 關閉
zephyrproject-rtos/zephyr — Issue #114741 Issue（Bug · 測試 · Linux Foundation 直屬）· mipi_dbi 的 api scenario 因為 filter 把 node label 拼成 mipi-dbi，在每個平台上都被濾掉：devicetree 的 label 不能有連字號，而 twister 是直接查字串，樹裡的 label 是 mipi_dbi；在真的有那個節點的 m5stack_cores3 上，照今天的拼法九個設定全被靜態過濾 · 2026-07-28 回報 · 自行修復 → PR #115831 merged（改正拼法並讓 scenario 在 native_sim 上跑；+61/-14、3 檔，sylvioalves、JarmouniA、danieldegrasse approve，kartben 合併，v4.5.0）· 2026-09-24 以 completed 關閉
zephyrproject-rtos/zephyr — Issue #119678 Issue（Bug · Raspberry Pi Pico · DMA · Linux Foundation 直屬）· 一個 channel 的錯誤會回報在同一次中斷裡後面的 channel 上：dma_rpi_pico_isr() 把 err 宣告在走訪待處理 channel 的迴圈外，無錯的那條路不歸零，於是低號 channel 的錯誤旗標讓後面每一個自己成功的 channel 也收到 -EIO；MIPI DBI 的 PIO driver 在 split 設定下一個裝置最多跑四個 channel，這條路到得了 · 2026-09-20 回報 · 自行修復 → PR #119681 merged（+2/-1，soburi 與 dsseng approve）· 2026-09-23 以 completed 關閉
zephyrproject-rtos/zephyr — Issue #119677 Issue（Bug · Raspberry Pi Pico · 顯示驅動 · Linux Foundation 直屬）· DMA 錯誤以 channel 號碼進入結果佇列，channel 0 的錯誤於是讀成成功：mipi_dbi_pio_dma_irq_handler() 出錯時把 channel 號碼丟進佇列，而等待端把佇列裡的值當成 transfer 的結果（PIO 完成路徑丟的是 0），所以 channel 0 的錯誤等於成功、其他 channel 回一個正數到呼叫端預期負 errno 的地方；channel 來自 dma_claim_unused_channel()、發的是最小的空號，第一個 split 拿到 0 的機會最大 · 2026-09-20 回報 · 自行修復 → PR #119680 merged · 2026-09-23 以 completed 關閉
zephyrproject-rtos/zephyr — Issue #119676 Issue（Bug · Raspberry Pi Pico · 顯示驅動 · Linux Foundation 直屬）· rpi_pico_pio 的 MIPI DBI driver 從沒初始化過 transfer mutex：mipi_dbi_pico_pio_write_helper() 鎖的 data->lock 在整個 driver 裡找不到 k_mutex_init，instance data 是零填的 static；零填的 wait queue head 是 NULL 而非 list 自己的位址，所以無競爭時僥倖能動，第一個真的阻塞的 thread 走到 sys_dlist_append() 就對 NULL 的 tail 寫下去。#115854 在 mipi_dbi_bitbang.c 修過同一個遺漏 · 2026-09-20 回報，修正同日送出 · 自行修復 → PR #119680 merged（與 #119677 同一支，+4/-1、一缺陷一 commit；dsseng、soburi、JarmouniA approve，掛 v4.5.0 與 backport v4.4-branch）· 2026-09-23 以 completed 關閉
kubernetes-sigs/kueue — Issue #14004 Issue（Bug · area/dra · CNCF）· extended-resource 的替換把那個 key 上的每一筆貢獻都刪掉，而不是它真正替換掉的那一筆：DRA-backed extended resource 進 quota 時，workload builder 刪掉整個 resource key 再補回由容器 request 重建的 charge，於是 spec.overhead 與以該資源為輸出的 transformation 一併消失；重建的數字本身也可能是錯的，因為 restartable init container 在一邊被加總、在另一邊被取 max，刪掉的卻是加總後的值 · 2026-08-08 回報 · 自行修復 → PR #14154 merged（只減掉容器自己的 request、sidecar 改為加總；+537/-64、8 檔，tenzen-y lgtm 與 approve，release note 標 ACTION REQUIRED；同日回移 0.19 與 0.18）· 2026-09-22 以 completed 關閉
AcademySoftwareFoundation/rawtoaces — Issue #326 Issue（Bug · 可攜性 · ASWF）· Docker 預設 seccomp 下 exiftool 每次呼叫都被判失敗：execute() 在 popen() 之後看 errno 決定成敗，但 popen() 只在回 NULL 時設 errno；glibc 的 posix_spawn 先試 clone3、被 seccomp 擋成 ENOSYS 後改走 clone 照跑，errno 卻留在 38，Test_Exiftool 與 Test_ImageConverter 的 fetch-metadata 案例在 Docker 裡紅、加 --security-opt seccomp=unconfined 就 17 個全綠，附三行 C 重現；順帶指出 popen() 回 NULL 時會呼叫 pclose(NULL)、pclose() 的結束狀態被丟掉 · 2026-09-11 回報，三分鐘後送修 · 自行修復 → PR #328 merged（改看 NULL 與 pclose() 結束狀態；soswow 抓到 EINTR 重試會丟半行，改成 fread() 計數迴圈；+199/-22、3 檔，antond-weta 合併）· 2026-09-21 以 completed 關閉
zephyrproject-rtos/zephyr — Issue #116336 Issue（Bug · ESP32 DMA · Linux Foundation 直屬）· AXI GDMA channel 沒經過 abort 握手就被 reset 與 stop：dma_esp32_stop() 在 AXI channel 上寫完 stop strobe 就回報成功、從沒證明 channel 已停，driver 其他地方 reset AXI channel 也略過硬體要求的 abort → 等 is_reset_avail → reset → 解除 abort 序列；#113311 讓「dma_stop() 成功」成為呼叫端收回 buffer 的依據之後，這件事在 AXI 上就不成立了。回報時自己更正過一次：原以為沒有 in-tree 路徑走 dma_axi，後來在 tests/ 找到 esp32p4 的 spi_loopback overlay 把 SPI2 掛在上面 · 2026-08-14 回報 · 自行修復 → PR #113311 merged（configure、reload、stop 三處 reset 都走一個 AXI-aware helper，sylvioalves 在 P4 上實測，+119/-17）· 2026-09-18 自行以 completed 關閉
kubernetes-sigs/dra-driver-cpu — Issue #231 Issue（Bug · 部署 · CNCF）· Helm chart 把 /var/lib/kubelet 寫死，kubelet 的 --root-dir 搬走後 driver 永遠註冊不上：kubelet 的 plugin watcher 只看 <root>/plugins_registry/，driver 卻把 registrar socket 建在寫死的路徑下，DaemonSet crash-loop、沒有任何 dra.cpu ResourceSlice，同節點的 NVIDIA driver 照常註冊 · 2026-07-08 回報，fix 當時已備好，但 #213 在改同一套 flag／config 接線，fmuyassarov 要求等它先落地；之後拆成三支：#244 加上兩個 kubelet 目錄 flag、#274 讓 chart 從單一 kubeletRootDir 推出參數與兩個 mount（皆已合併），最後一支 · 自行修復 → PR #282 merged（chart 拒絕 kubelet 只在參數裡改寫的 $(／$$ 序列，並把接線放進 CI 的 render check 與 relocated-root e2e lane；ffromani 兩輪共 15 則意見後把測試從 936 行砍到 209 行，9/17 approve；+534/-7、12 檔、kind/bug）· ffromani 8/12 就說「#282 合併即可關」，Issue 以 completed 關閉
volcano-sh/volcano — Issue #5627 Issue（Bug · 安全／DoS · CNCF Incubating）· addDRAResource 對使用者可控的 DRA device count 做無上界迴圈，一個 Pod 就能吊死 scheduler：per-DeviceClass 的容量總和用「迭代 count-1 次、每次 totalQty.Add()」算，count 直接來自 ResourceClaim 的 Exactly.Count，apiserver 只擋 <= 0，2^63 級的 count 讓處理該 Pod 的 goroutine 永遠不回來、記憶體也隨之無界成長（CWE-400 經由 CWE-834）· 2026-07-10 回報，vivek41-glitch 當天認領，我把迴圈修正讓給他、自己守著 #5625 的負數繞過那一半；7/12 同時通報 Volcano PST，8/4 JesseStutler 受理為 security vulnerability 並承諾 GHSA 與 v1.15.2；他的 #5640 最後沒有解決，8/10 JesseStutler 請我接回 · 自行修復 → 修正在私有 advisory fork 內開發、以 master commit c7fb3fe7 落地（Quantity.Mul 以 O(1) 相乘、溢位時升成 inf.Dec，+72/-8），再以 #5869 merged 帶回 release-1.15；GHSA-j38h-7pfq-cxmw 8/26 發佈、本人具名 finder，修正隨 v1.15.2 出貨 · 9/17 JesseStutler 留下「Done」、Issue 以 completed 關閉
kubernetes-sigs/kueue — Issue #14105 Issue（Bug · 配額會計 · CNCF）· workload 用量飽和到 math.MaxInt64 就與「無上限」的哨兵分不開，之後別人加進來不計、離開時照減，帳面漂到負數直到重啟：Amount 只在 quota 邊界擋哨兵值，usage 邊界的 Mul 與 AddInt64 卻是飽和的，四個 Pod 各要 2^62 就正好落在哨兵上；8/11 再找到第三條路，SafeValue 的 clamp 直接瞄準 MaxInt64；8/15 自己先試的 clamp #14519 量到只擋碰撞、擋不了移除時的漂移，當天關掉並寫下需要可回復的表示法 · mimowo 8/31 確認、提議內部改用 big，9/2 同意把 MaxInt64 編碼當實作細節 · 自行修復 → PR #15026 merged（Amount 改為 int64 放得下就 int64、放不下轉 big.Int 的精確整數，+1498/-351、21 檔、kind/bug·release-note；mimowo 要求 benchmark 前後比較、把 fair sharing 與 metrics 的改動拆出去、fuzzer 換表格測試後 lgtm+approve，稱其修的是 workload 建立者能挾持配額的漏洞；0.19 與 0.18 的 cherry-pick #15653／#15654 皆於 2026-09-17 合併）· Issue 以 completed 關閉
k8snetworkplumbingwg/dra-driver-sriov — Issue #136 Issue（Bug · 跨 driver 狀態遺失）· 撞到 conflict 的重試會把別的 driver 在衝突視窗內寫進 status.devices 的條目蓋掉，而且重試接著成功、沒有人會發現：status.devices 由同一個 ResourceClaim 上所有出過裝置的 driver 共用，所以在它上面撞到 conflict，最可能的對手正是共用這份清單的另一方；兩條重試路徑卻都先整份存起來、refetch 之後再整份指派回去，對方的寫入就這樣被一份舊快照覆蓋 · 自行修復 → PR #137 merged（改為在最新的 claim 上重建本 driver 自己的條目，+799/-71、8 檔）· 2026-08-04 回報、2026-09-14 由 SchSeba 合併並關閉 · 跨廠商 DRA driver 稽核中「多-driver claim」家族的一支，這次落在 status-retry 路徑
k8snetworkplumbingwg/dra-driver-sriov — Issue #138 Issue（Bug · 身分錯置）· 重試時 refetch 只按 namespace 與 name 取回 claim、不核對 UID，claim 被刪掉重建時狀態會寫到一個同名但不是同一個的物件上：pkg/driver/dra_hook.go 的 prepareResourceClaim 與 pkg/nri/nri.go 的 updateClaimNetworkDataWithRetry 兩處皆是。做 #137 時順帶發現 · 自行修復 → 同一支 PR #137 merged · 2026-08-06 回報、2026-09-14 由 SchSeba 以 commit dc1c0da 關閉
ocudu/ocudu — Issue #726（GitLab） Issue（Bug · OFH U-plane · 遠端可觸發）· 對端只要宣告一種這個 build 沒有實作的壓縮型別，整個 gNB process 就結束：create_iq_decompressor() 對其中五種（block scaling、mu-law、modulation、bfp selective、mod selective）回傳 iq_compression_death_impl，而它呼叫 report_error()、最後走到 std::quick_exit(1)。動態壓縮解碼器的型別讀自線上 section 的 udCompHdr，所以一個畸形的上行 fronthaul 封包就足夠；靜態解碼器的型別取自設定，不受影響。以 U-plane 解碼器搭配真實的解壓縮器選擇邏輯做 fuzz 找到 · 自行修復 → MR !1296 merged（decompress() 改為回傳 bool 表示有沒有產出 IQ 樣本，呼叫端據此丟棄該訊息，39 檔）· 2026-08-18 回報、2026-09-14 由 faluco 關閉 · 第一版在解碼器內部加守衛，AleaLC 於討論串提出另一種作法、faluco 同意，整個 diff 重寫為第二版
AcademySoftwareFoundation/rawtoaces — Issue #325 Issue · DNG 解算器的線性內插往括號外落，回報的色溫不是它自己算出來的根：find_camera_to_XYZ_matrix 在兩個校準光源之間掃描、誤差變號時於相鄰兩點之間內插，式子寫成 current_mired + 而該是 -。測試素材上解算器報 5317K、該處殘差 8.4 mired，真正的根在 5566K、殘差 0.0001 mired。只有單一 ColorMatrix 的 DNG 原本是靠這串錯誤互相抵銷才碰巧正確，掃描一修好反而會朝全零矩陣內插 · 自行修復 → PR #327 merged（修內插方向，另修被跳過的取樣把 last_error 留在 0、掃描沒有收在 high_mired 兩處，並比照 DNG SDK 的條件才啟動掃描，+254/-43、5 檔）· 2026-09-11 回報、2026-09-14 關閉 · Issue 以 completed 關閉
AcademySoftwareFoundation/rawtoaces — Issue #329 Issue · exiftool 的兩個路徑都沒加引號就交給 shell，含空白的檔名讓呼叫「成功」卻拿不到任何 metadata：exiftool 對每個被拆開的片段各印一次 File not found，stdout 不是空的，於是 fetch_metadata 回 true 而 metadata 全空。因為整行經過 shell，未加引號的檔名也能執行命令，名為 a;id;.NEF 的檔案就會跑 id · 自行修復 → PR #330 merged（兩個路徑都上引號、影像路徑前加 --，+89/-2、2 檔）· 2026-09-11 回報、2026-09-14 關閉 · Issue 以 completed 關閉
kubernetes/kubernetes — Issue #141323 Issue（Bug · sig/node · wg/device-management · priority/important-soon）· DRA structured allocator 的 per-claim 裝置上限檢查用原生 int 加總 device count：加總越過平台的 int 邊界即繞成負數，上限檢查於是放行一個實際上超過該 claim 允許裝置數的請求 · 自行修復 → PR #141307 merged（+148/-75）· 2026-08-12 回報、2026-09-12 關閉 · #141307 於 9/7 合併後 pohly 為追 1.34 至 1.37 的 backport 把 issue 重新開啟，四支 cherry-pick（#141925、#141924、#141923、#141922）於 9/12 全數合併後才再次關閉 · Issue 以 completed 關閉
kubernetes/kubernetes — Issue #141617 Issue · PVC 指名 PV 時的容量比較走會溢位的 Quantity.Value()：checkVolumeSatisfyClaim 把容量與請求投影到 int64 再比，儲存量一過 int64 就 wrap：容量 2^63 讀回來是負數，1Gi 的 claim 指名它會被以「requested PV is too small」拒絕、停在 Pending；反方向請求 wrap 之後，比請求小的 PV 反而通過，邊界只有一個單位寬（MaxInt64 對 MaxInt64 + 1）。自動配對那條路的 FindMatchingVolume 早就用 Cmp · 自行修復 → PR #141618 merged（改用 Cmp，+46/-3）· 2026-08-27 回報、2026-09-11 關閉 · Issue 以 completed 關閉
nephio-project/nephio — Issue #1171 Issue · FOCOM 的 PorchStorage 自己蓋掉 client-go 的 Authorization 標頭，於是 exec 認證與 token 輪替都失效：makeRequest 用建構當下讀到的 token 自行設標頭，而 client-go 的兩個憑證包裝器（bearer-token-file 更新器與 exec plugin）在標頭已存在時都會跳過注入。exec 型 kubeconfig 的 plugin 因為那個空的 Bearer 永遠不會執行；projected service account token 被 Kubernetes 輪替後 operator 仍送啟動時那一份，開始從 Porch 收到 401 直到重啟 · 自行修復 → PR #1181 merged（把憑證移到 rest.Config、拿掉手設的標頭，讓 client-go 負責簽請求，+1372/-238、12 檔）· 2026-08-16 回報、2026-09-10 關閉 · Issue 以 completed 關閉
open-telemetry/opentelemetry-cpp — Issue #4425 Issue · OTLP HTTP exporter 在三個 client 可能結束的狀態上永遠不判定請求完成：ResponseHandler::OnEvent 的 switch 只列了七個狀態，Destroyed、ReadError、WriteError 會被記錄卻不算結束，請求到不了 Unbind、結果 callback 不執行、session 不釋放，ForceFlush 與 Shutdown 只能等到自己逾時，呼叫端等一個不會來的 callback · 自行修復 → PR #4453 merged（把三個狀態併進同一個 switch，+117/-0）· Issue 以 completed 關閉
kubernetes-sigs/kueue — Issue #14398 Issue · 開了 ClusterQueue 自訂指標標籤之後，第一次移除 scheduling gate 就會 panic 掉 controller：PodSchedulingGateRemovalSeconds 這個 vector 註冊時帶的是三個固定標籤加上設定裡的 ClusterQueue 自訂標籤，RecordPodSchedulingGateRemovalSeconds 卻只傳三個值進去，數量對不上就 panic，manager 隨 ungaters 一起倒 · 自行修復 → PR #14419 merged（把該筆指標連同它的 ClusterQueue 自訂標籤一起記錄，+560/-36、19 檔）· 2026-08-13 回報、2026-09-10 關閉 · Issue 以 completed 關閉
publiccodeyml/publiccode.yml — Issue #363 Issue · 舊版文件網址轉址時把 query string 丟掉，照著舊搜尋連結進來的人會落在一個空的搜尋頁：轉址只接 location.hash，/search.html?q=maintenance 於是轉到不帶 ?q= 的新版搜尋頁，而落地頁的 Search.init() 是從 query string 讀 q、讀不到就不執行搜尋 · 自行修復 → PR #364 merged（把 query 接在 fragment 之前，+1/-1）· 2026-09-09 回報、同日關閉 · Issue 以 completed 關閉
kubernetes-sigs/kernel-module-management — Issue #1346 Issue · 兩個 namespace 有同名 Module 時，節點上的 plugin ready label 會被留下：PodNodeLabelReconciler 摘標籤前會先找替補 Pod（免得 DaemonSet 滾動更新讓標籤閃爍），但那個查找沒限定 namespace，把另一個 namespace 的同名 Module 當成替補 · 自行修復 → PR #1347 merged（把查找限定在 Module 自己的 namespace，+147/-17）· 2026-09-09 回報、同日關閉 · Issue 以 completed 關閉
cncf/prow-github-actions — Issue #102 Issue · 指令 handler 在自己的 GitHub API 呼叫完成前就回傳，非同步副作用沒有被 await，action 可能在留言、加標籤等請求真正送出前結束 · 自行修復 → PR #103 merged（+368/-225、15 檔，CNCF 的 jeefy 合併）· Issue 以 completed 關閉
cncf/prow-github-actions — Issue #105 Issue · 移除標籤失敗被吞掉：真正的 API 錯誤不會讓 action 失敗，維護者以為指令生效、實際沒有 · 自行修復 → PR #106 merged（遇到真正的移除錯誤即讓 action 失敗，+119/-4，CNCF 的 jeefy 合併）· Issue 以 completed 關閉
kubernetes/kubernetes — Issue #140797 Issue（Bug · sig/node · wg/device-management）· structured DRA allocator 會把仍有存活持久化共享配置的裝置再獨佔配置出去：allocateDevice 用 deviceInUse 擋不可用裝置，但它只檢查 AllocatedDevices 與 in-flight 的 allocatingDeviceForAnyClaim，沒檢查已持久化的共享配置；allowMultipleAllocations 關閉之後，同一裝置就可能同時掛著一份共享與一份獨佔 · 自行修復 → PR #140798 merged（+72/-0、3 檔、kind/bug·release-note、Prow 合併）· Issue 以 completed 關閉 · 2026-07-21 回報、2026-09-04 修正合併
kubernetes-sigs/dra-driver-cpu — Issue #308 Issue（Feature · 非缺陷）· Helm chart 的 values 根物件是唯一沒關起來的一層，打錯的頂層鍵會被安靜接受然後忽略，chart 照預設值算圖：values.schema.json 對 args、image、rbac、resources 與內附的 driverConfig 都設了 additionalProperties: false，唯獨根層沒有，於是 --set-string bogusTopLevelKey=x 不報錯而 --set-string args.bogusKey=x 會報錯。落在 kubeletRootDir 上就是 kubelet 路徑以預設值算圖，而操作者以為自己設好了 · 自行修復 → PR #309 merged（把根層一併關起來，+25/-0、3 檔、kind/feature、lgtm＋approved、Prow 合併）· 審查自己的 #282 時順手發現、當日回報並修復、2026-09-01 關閉 · 同樣是自提並實作而非缺陷，依「自報自修並合併」計入 · Issue 以 completed 關閉
microsoft/retina — Issue #2678 Issue（Bug · panic）· 任何非 TCP/UDP 的流量（ICMP、SCTP）都會讓 port metric context 打掛 metrics module：這類流量根本沒有 port，metric context 仍照取，整個 metrics module 就 panic · 自行修復 → PR #2679 merged（這類流量一律送出一個 port 值，順帶讓 label cardinality 保持一致，+38/-0）· Issue 以 completed 關閉 · Microsoft 的 eBPF Kubernetes 網路可觀測性
Gthulhu/Gthulhu — Issue #132 Issue（Bug · 排程實體錯位）· 節點排程政策只掃 PID（thread-group leader），沒掃真正的排程實體 TID：Linux 排程的單位是 TID，多執行緒工作負載下政策只套到 leader，其餘執行緒完全沒被涵蓋 · 自行修復 → 跨兩個 repo 兩支 PR merged：Gthulhu #135（decisionmaker 改掃 /proc task 執行緒，+393/-82）與 plugin #17（策略以 TID 套用、TGID 只當 fallback，+233/-66）· Issue 以 completed 關閉
kubernetes-sigs/kueue — Issue #13988 Issue（Bug · 靜默覆寫）· 名為 pods 的 DeviceClass mapping 或 transformation 輸出會被接受，然後靜默被 PodSet 數量取代：設定通過驗證、看起來生效，實際上該名稱的值被 PodSet 數量蓋掉 → 配額記到的東西跟使用者宣告的不是同一個 · 自行修復 → PR #13989 merged（在驗證階段直接拒絕這個保留名稱，+308/-6；並 cherry-pick 至 release-0.18 #14758）· Issue 以 completed 關閉
kubernetes-sigs/kueue — Issue #14744 Issue（Bug · 測試污染）· CustomMetricLabels 整合測試把共享 metric vector 加寬後沒還原，後面的 spec 一跑就 panic：「Job controller with CustomMetricLabels」區塊改寬了共享的 metric vector、結束時沒重置 → 後續 spec 讀到寬掉的 vector、維度對不上就 panic · 自行修復 → PR #14745 merged（測試結束重置共享 vector，+1/-0）· Issue 以 completed 關閉
kubernetes-sigs/cluster-autoscaler — Issue #31 Issue（Bug · nil 解參考 · DRA）· 移除節點時 Pod 若 reference 未追蹤的 DRA ResourceClaim，cluster-autoscaler 會 nil-pointer panic：findPodClaims 在寬鬆路徑（ignoreNotTracked）用 continue 跳過未追蹤／無名 claim、卻在對應 index 留下 nil 洞；RemovePodOwnedClaims 逐一 GetClaimId 就對 nil *ResourceClaim 解參考、CA panic，一個這種 Pod 就能打掛整個 CA loop（DRA 啟用時）· 自行修復 → PR #32 merged（改用零長 slice + append、只加實際找到的 claim，+82/-4）· Issue 以 completed 關閉
prometheus/prometheus — Issue #19432 Issue（Bug · nil 解參考）· promtool tsdb create-blocks-from rules 遇到含多份 YAML 文件的 rule 檔會 panic：default group loader 只想警告「只處理第一份文件」，卻在 logger 還沒設好時就拿它記錄 → nil logger 解參考、crash · 自行修復 → PR #19433 merged（default group loader 補 nil-safe logger，Closes #19432，+33/-4）· Issue 以 completed 關閉 · CNCF Graduated 監控系統
kubernetes-sigs/kueue — Issue #14399 Issue（Bug · nil 解參考）· 沒有 priority 的 pending Workload 讓 visibility endpoint panic：newPendingWorkload 直接解參考 *wlInfo.Obj.Spec.Priority，但 Workload.Spec.Priority 是可合法為 nil 的 *int32（無全域預設 priority 時建立的 Workload）→ visibility pending-workloads endpoint nil-deref panic · 自行修復 → PR #14411 merged（改 nil-safe 取值，Closes #14399，+38/-1）· Issue 以 completed 關閉
zephyrproject-rtos/zephyr — Issue #115720 Issue（Bug · 狀態機）· esp32 GDMA 把 block_size 為 0 的 block 建成長度 0、owner=DMA 的 descriptor 交給硬體：dma_esp32_config_descriptor() 直接拿 block size、不做檢查，0 長度 block 也被填成 DMA-owned descriptor 送進硬體 · 自行修復 → PR #115723 merged（拒收零長度 block，Closes #115720，+10/-0）· Issue 以 completed 關閉
zephyrproject-rtos/zephyr — Issue #115504 Issue（Bug · 資源洩漏）· esp32 i2s TX start 失敗弄丟已從 mem-slab 取出的 block：底層 DMA 啟動失敗就直接 return，先前從 slab 取出並入佇列的 block 沒還回去 → 每次失敗漏一塊、TX slab 終究耗盡 · 自行修復 → PR #115523 merged（失敗路徑把 block free 回 slab，Closes #115504）· Issue 以 completed 關閉
zephyrproject-rtos/zephyr — Issue #115719 Issue（Bug · NULL 解參考）· esp32 i2s 對不支援的 trigger 方向解參考 NULL stream：trigger 落在未配置的方向時直接取用該方向的 stream 指標 → NULL deref crash · 自行修復 → PR #115721 merged（先擋不支援方向、回 -ENOSYS，Closes #115719）· Issue 以 completed 關閉
zephyrproject-rtos/zephyr — Issue #115505 Issue（Bug · 狀態機）· esp32 i2s deferred TX timer 在停止後從不取消：DROP/stop 沒取消已排入的 timer → timer 事後才觸發、打到已停的串流或下一段串流 · 自行修復 → PR #115725 merged（stop 時一併取消 timer，Closes #115505）· Issue 以 completed 關閉
ocudu/ocudu — Issue #643 (GitLab) Issue（Bug · use-after-free）· NTN SIB19 更新把 dangling span 與 request reference 交給延後的 async task：SI messages 建在堆疊、只把非持有 span 與 by-reference 捕獲的 request 交給 DU manager 延後執行；handler 返回、堆疊 unwind 後兩者皆已釋放，後續 DU update 與 MAC reconfiguration 讀已釋放記憶體 · 自行修復 → MR !1153 merged（request 改持有 buffers、by-value+move 端到端傳遞，ASan+mutation testing 驗證，Closes #643、maintainer Piotr Gawłowicz 合併）· Issue 以 completed 關閉
kubernetes-sigs/kueue — Issue #13902 Issue（Bug · 併發）· 一個失敗的 errgroup 分支會把其他獨立分支一起取消：LeaderWorkerSet/StatefulSet reconciler 的獨立操作共用同一個 errgroup.WithContext，任一支失敗就 cancel 掉共用 context → 本可獨立完成的其他操作被連累中止 · 自行修復 → PR #13921 merged（讓失敗分支不再取消其他，Closes #13902、+250/-2、kind/bug·release-note、Prow 合併）· Issue 以 completed 關閉
zephyrproject-rtos/zephyr — Issue #115502 Issue（Bug · 越界/記憶體安全）· descriptor-exhaustion 檢查對 desc_list 尾端後一格解參考，dma_esp32_reload 還往那寫：dma_esp32_gdma.c 的耗盡檢查越過 desc_list 尾端一格、dma_esp32_reload() 對該越界位置寫入 · 自行修復 → PR #115507 merged（一發雙修，Closes #115502，+168/-15、6 檔）· Issue 以 completed 關閉
zephyrproject-rtos/zephyr — Issue #115503 Issue（Bug · 控制流）· dma_esp32_stop() 在 memory-to-memory 分支後 fall through，把同一方向停兩次：M2M 分支缺 break/return、控制流落到下一段 → 同一 DMA 方向被停兩次 · 自行修復 → PR #115507 merged（同一支、一發雙修，Closes #115503）· Issue 以 completed 關閉
open-telemetry/opentelemetry-cpp — Issue #4375 Issue（Bug · data race）· HttpOperation::Abort 從取消執行緒寫 curl easy handle，與 IO 執行緒同時驅動同一 handle 競爭：Abort() 在呼叫 CancelSession() 的執行緒上跑 curl_easy_setopt，IO 執行緒卻同時在該 easy handle 上驅動傳輸 · 自行修復 → PR #4392 merged（改為不跨執行緒寫 easy handle、走事件通道取消，Fixes #4375、+86/-22、kind/bug）· Issue 以 completed 關閉
kubernetes-sigs/kueue — Issue #14012 Issue（Bug · nil panic）· Workload validating webhook 在 QuotaReserved condition 沒有 status.admission 時 panic：ValidateWorkload 用 HasQuotaReservation 判斷後就進 validateAdmission 讀 admission，但那個 condition 可以在沒有 admission 的情況下被設 → 對 nil admission 解參考、webhook panic · 自行修復 → PR #14014 merged（不因 condition 宣稱就讀 admission，Closes #14012、+83/-2、kind/bug·release-note、Prow 合併）· Issue 以 completed 關閉
open-telemetry/opentelemetry-cpp — Issue #4389 Issue（Bug · deadlock）· resetMultiHandle 從 curl multi error 復原時自我死鎖在 sessions_m_：resetMultiHandle() 整個函式持有 sessions_m_，中途又呼叫同執行緒會再取該鎖的 CancelSession()（→CleanupSession）→ 同執行緒重入、死鎖 · 自行修復 → PR #4394 merged（把鎖範圍縮到快照那段，Fixes #4389、+47/-1、kind/bug）· Issue 以 completed 關閉
RocketPy-Team/RocketPy — Issue #1042 Issue（Bug · 可重現性）· 感測器量測雜訊用 process-global NumPy RNG、無法設種子（不可重現）：Sensor/InertialSensor/ScalarSensor 的白噪與 random-walk bias 漂移、以及 GnssReceiver 的位置/高度精度都從全域 NumPy RNG 抽 → 給了 seed 也重現不了 · 自行修復 → PR #1052 merged（讓量測雜訊可逐實例設種子，+279/-19；#1052 body 明指本 issue、由本人以 completed 關閉，GitHub 未自動 link 故其 closes 為空）· Issue 以 completed 關閉
open-telemetry/opentelemetry-cpp — Issue #4398 Issue（Bug · data race）· curl retry path 共用一個 jitter generator（shared mutable static）→ 多執行緒重試相互競爭：HttpOperation::NextRetryTime() 的 backoff jitter 從 static std::mt19937 抽樣，多個重試同時抽樣即資料競爭（-fsanitize=thread 確認）· 自行修復 → PR #4399 merged（改為 per-thread generator，Fixes #4398 的 data race 部分、+38/-3、kind/bug）· Issue 以 completed 關閉（同 issue 另列兩點屬 code-reading 觀察、非確認 bug）
kubernetes-sigs/dra-driver-cpu — Issue #254 Issue（Bug）· 註冊逾時吞掉 kubelet 最後一次的拒絕原因：driver 在 pkg/driver/driver.go 以 30 秒輪詢等註冊，只回 status.PluginRegistered、從不 surface status.Error → kubelet 持續回報 rejected 時，呼叫端只看到逾時、拿不到 kubelet 給的理由（診斷困難）· 自行修復 → PR #291 merged（把 kubelet 的拒絕理由一併回報，Closes #254，+161/-9、kind/bug、Prow 合併）· Issue 以 completed 關閉
kubernetes-sigs/kueue — Issue #14043 Issue（Bug · DRA · 配額會計）· DRA extended-resource 配額被記到 scheduler 未必會 allocate 的 DeviceClass：多個 DeviceClass 宣告同一個 spec.extendedResourceName 時，resolveContainerExtendedResources 取「List 回傳中第一個帶 deviceClassMappings 的 class」的 quota key，而非 scheduler 實際會 allocate 的那個 → 配額記錯 class · 自行修復 → PR #14044 merged（改為對 scheduler 會 allocate 的 class 計費，Closes #14043，+209/-33、kind/bug·release-note、Prow 合併）· Issue 以 completed 關閉
kubernetes-sigs/kueue — Issue #13998 Issue（Bug · 配額會計 · int64）· 正的 transformation 乘積 wrap 成負 request、再被 floor 到 0：ResourceValue 只守 CPU 路徑（走 SafeMilliValue），其他資源直接 q.Value() → 超出 int64 範圍的量被靜默截斷（SafeValue 就是為此存在、註解明講「避免 resource.Quantity.Value() 對超 int64 量的靜默截斷」）· 自行修復 → PR #14042 merged（改為每個資源都 clamp，Closes #13998，+91/-4、kind/bug·release-note、Prow 合併；release-0.18 backport #14113）· Issue 以 completed 關閉
kubernetes-sigs/kueue — Issue #13985 Issue（Bug · 配額會計）· 用負係數寫的 per-unit allowance 被花到產生它的 transformation 之外：resource transformation 把 input 乘上各 output 係數並以該名字累加；負係數是「每單位額度（allowance）」的寫法，charge 應是請求超出額度的部分。但該額度會外溢、被算到不該碰的資源上 → 配額算錯 · 自行修復 → PR #13986 merged（把「transformation 產生的量」與「PodSet 請求的量」分開，Closes #13985，+313/-26、kind/bug·release-note、Prow 合併；release-0.18 backport #14033）· Issue 以 completed 關閉
kubernetes-sigs/kueue — Issue #13992 Issue（Bug · 配額會計）· Retain+multiplyBy 保留的是「乘積」而非「原請求量」：applyResourceTransformations 在 multiplyBy 設定時把迴圈的 inputQuantity 重新賦值成乘積，接著 Retain 又把這個已被乘過的值寫回 input 自己的名字下 → 被保留的量變成乘積、配額被灌大 · 自行修復 → PR #13986 merged（同一支 PR、一發三修，Closes #13992）· Issue 以 completed 關閉
kubernetes-sigs/kueue — Issue #13990 Issue（Bug · 配額會計 · 非決定性）· transformation output 與請求資源同名時，依 map 迭代順序被保留或丟棄：applyResourceTransformations 累加 transformation 的 outputs，卻用 assignment 寫回被保留/未轉換的 inputs → 當某 output 名字與請求資源同名，最後留下誰取決於 map 迭代順序、配額被保留或丟棄 · 自行修復 → PR #13986 merged（同一支 restructure 一併修好；#13986 cross-reference 本 issue、由本人以 completed 關閉，GitHub 未自動 link 故 #13986 的 closes 只列 #13985/#13992）· Issue 以 completed 關閉
RocketPy-Team/RocketPy — Issue #1101 Issue（CI）· fork 來的 PR 每次都跑不了 Populate Changelog：GitHub 對 fork PR 扣留 secrets，changelog job 因而一律失敗 · 自行修復 → PR #1112 merged（讓 changelog job 也對 fork PR 執行，同一 PR 亦關閉維護者的自動化 issue #905）· Issue 以 completed 關閉
RocketPy-Team/RocketPy — Issue #1096 Issue（文件）· CustomSampler 文件教的 reset_seed 其實什麼都沒做：文件示範一個無效的 reset_seed 用法、誤導使用者 · 自行修復 → PR #1097 merged（文件改成有效做法）· Issue 以 completed 關閉
RocketPy-Team/RocketPy — Issue #1078 Issue（測試穩定性）· test_flight_animation_export_gif 間歇性 bus error（flaky）：該測試偶發崩潰、汙染 CI 訊號 · 自行修復 → PR #1100（+#1098）merged · Issue 以 completed 關閉
RocketPy-Team/RocketPy — Issue #1093 Issue（Bug）· stochastic 模型裡每個 CustomSampler 都用同一個 seed 重置：兩個以 default_rng 建的 sampler 從相同狀態出發、抽出逐位元相同的值（兩個不同均值/變異的 Gaussian 都吐 0.466220770577340）→ 掃兩個參數實為掃一個、報出的相關性是 seeding 假象。改為每個 sampler 依 model seed + input 名字派生獨立子流（以名字為 key、crc32 求跨行程穩定）· 自行修復 → PR #1102：整條 7-commit branch 已併入 develop（PR 顯示 closed 而非 merged、走 merge 鈕以外路徑，commit 如 6d66bde5 可查）· Issue 以 completed 關閉
RocketPy-Team/RocketPy — Issue #1094 Issue（Bug）· 抽樣出的降落傘幾何從未進到 StochasticRocket 建的火箭：StochasticParachute.create_object() 依完整抽樣建出 Parachute（10 個欄位），StochasticRocket.create_object() 隨即丟棄、只取其中 6 個欄位重建 → 抽樣到的降落傘幾何沒進到實際模擬飛的火箭 · 自行修復 → PR #1098 merged（+104/-9、maintainer Gui-FernandesBR 合併）· Issue 以 completed 關閉
RocketPy-Team/RocketPy — Issue #1095 Issue（Bug）· StochasticParachute 拒絕自己 docstring 承諾可傳的 callable trigger：_validate_trigger 文件說 trigger 可傳函式，驗證卻只認數值/字串、把 callable 擋掉 · 自行修復 → PR #1103 merged（+150/-9、maintainer Gui-FernandesBR 合併）· Issue 以 completed 關閉
RocketPy-Team/RocketPy — Issue #1107 Issue（Bug · 封裝）· 宣告的相依下限低到裝了也 import 不了套件：setup 寫 numpy>=1.13、scipy>=1.0，照這最低相依裝起來根本 import 不了 RocketPy · 自行修復 → PR #1108 merged（把下限提到真正跑得起來的版本、maintainer Gui-FernandesBR 合併）· Issue 以 completed 關閉
RocketPy-Team/RocketPy — Issue #1099 Issue（CI）· docs build workflow 對 develop 的 PR 不會跑：只在 PR→master 觸發，但近期多數 PR 進 develop（近 30 筆有 25 筆）→ 文件破圖要到進 master 才被抓到 · 自行修復 → PR #1104 merged（讓 PR→develop 也 build 文件、maintainer Gui-FernandesBR 合併）· Issue 以 completed 關閉
ocudu/ocudu — Issue #632（GitLab） Issue（Bug · CI 完整性）· 靜態分析跑不完也算通過：analyze 的 exit code 被 || true 吞掉，唯一的關卡是對報告內容做 severity grep，於是分析 crash、被 kill、零動作或零執行時，仍會發佈一份 partial 或空的 Code Quality 報告，而 MR 顯示綠燈：分析愈是沒跑起來，報告愈乾淨，看起來愈像通過 · 自行修復 → MR !1146 merged（改為 fail-closed：擷取 analyze 與 cppcheck-suppression 的 exit code、掃 codechecker_output/failed/、要求非空的 action manifest，並以 job 的 --analyzers 旗標核對 metadata.json）· 2026-07-26 回報、2026-08-07 由 asaezper 合併並關閉
kubernetes-sigs/kueue — Issue #13913 Issue（Bug · area/core）· 正在被逐出的 workload slice 被誤選為 chain 的 active slice：FindLatestActiveWorkload 回傳仍持配額保留的最新 slice，但 eviction 是兩段寫入（先設 Evicted condition、後釋放保留），夾在中間觀察到的 slice 仍回報有保留 → 可能回傳配額正在釋放的 slice。elastic job ungater 拿它的 granted counts 當解除 ElasticJobSchedulingGate 的上限 → 放行過多 pod（舊 slice 給 1、evicting slice 給 3、兩個 gated pod 原本兩個都放行；回歸測試未修 count=2、修後 count=1）。附帶修 normalizeActiveSlices 同秒 slice 排序與 FindNotFinishedWorkloads（#12931）不一致 · 自行修復 → PR #13914 merged（+256/-11、5 檔、kind/bug · release-note、Closes #13913、lgtm+approved、Prow 合併）· release-0.18 backport #13925 merged（比照 #13872 backport）· Issue 以 completed 關閉
kubernetes-sigs/kueue — Issue #13778 Issue（Bug · area/integrations）· Workload slicing 在相容路徑丟失 WorkloadPriorityClass label 變更：對 elastic Job，pod set 數量沒變時改 kueue.x-k8s.io/priority-class label 不會更新既有 Workload：ensureOneWorkload 的 slicing 分支一判定相容就 return，落在唯一套用優先權轉換的 UpdateWorkloadPriority 之前，label 變更被接受卻無效、無事件（合法 class 改成另一個合法 class 也照吞）· 自行修復 → PR #13780 merged（+1020/-11、kind/bug · release-note，Closes #13778，maintainer mimowo approved）· backport：release-0.19（robot #13871；該 CP 誤把已發布的 exported UpdateWorkloadPriority 簽名改成 variadic、破壞 0.19.0 API，本人 #13876 還原簽名、variadic 形式改走 unexported helper，merged）、release-0.18 由本人手動 cherry-pick（auto-CP 衝突後改 workloadpatching.PriorityClassName→workload.PriorityClassName）#13872 merged（同樣把 exported 簽名帶成 variadic，本人 #13877 還原 0.18 API、merged）· Issue 以 completed 關閉
kubernetes-sigs/dra-driver-google-tpu — Issue #26 Issue · prepareDevices 把 TPU 專屬檢查套到別 driver 的 allocation result：一個 ResourceClaim 可由多個 driver 一起滿足，prepareDevices 卻對整包 Results 都跑 full-chip 數、allocatable 查找與 container edits → claim 同時含別 driver 裝置時，完整 TPU 配置反被拒、錯誤訊息還文不對題 · 自行修復 → PR #25 merged（只處理 result.Driver == DriverName 的 result，把官方 dra-example-driver 本就有的守衛補回，Fixes #26，kind/bug、Prow 合併）· Issue 以 completed 關閉
IBM/power-dra-driver — Issue #322 Issue · prepareDevices 的 result 迴圈對別 driver 的裝置回 not allocatable：config 路徑的 GetOpaqueDeviceConfigs 早就跳過別 driver，result 迴圈卻對每筆 result 都查自家 allocatable → 混用兩 driver 的 claim 整包 not allocatable、pod 起不來 · 自行修復 → PR #323 merged（result.Driver != DriverName 就跳過，Fixes #322，maintainer prb112 合併）· Issue 以 completed 關閉
argoproj/argo-workflows — Issue #16576 Issue（Feature · 非缺陷）· Template API 表達不出 pod 層的 DRA resource claim，容器端的 resources.claims 只能指向一個它無法宣告的項目：DRA 在 Kubernetes v1.34 GA，Argo 早已有容器那一半的 template.container.resources.claims，卻沒有型別化的 pod 層對應欄位（v4.0.8 上 kubectl explain workflows.spec.templates.resourceClaims 回「field does not exist」），唯一的設法是整包手寫進 podSpecPatch · 自行實作 → PR #16587 merged（在 WorkflowSpec 與 Template 上加 resourceClaims，template 的清單整份取代 workflow 的、podSpecPatch 仍後套；驗證只做屬於 Argo 的那一半，不產生 pod 的 template 宣告 claim 即為錯誤，其餘交給 API server；feature gate 關閉時欄位被靜默丟棄則由 controller 警告，+3343/-2、33 檔）· 2026-07-30 回報、2026-07-31 關閉 · Joibel approved 並合併，merge commit c5cb81b · 這筆是自提的功能需求而非缺陷，與清單其餘各筆的性質不同，依「自報自修並合併」計入 · Issue 以 completed 關閉
open-telemetry/opentelemetry-cpp — Issue #4288 Issue · HttpServer 在 handleConnectionClosed() 以 map::erase 銷毀 Connection 後仍存取它（use-after-free）：m_connections 是 std::map<Socket, Connection>，handler 回傳 -1 觸發 handleConnectionClosed() 的 erase 後，processRequest() 未 return 就續寫 conn.response.*、組 status line、對已關 socket sendMore · 自行修復 → PR #4289 merged（Fixes #4288）· Issue 以 completed 關閉
open-telemetry/opentelemetry-cpp — Issue #4296 Issue · Elasticsearch 同步匯出可能因遺失通知永久阻塞：ResponseHandler::waitForResponse() 在無述詞的 cv_.wait(lk) 上等待；OnResponse 在釋放鎖後才 notify_all，通知早於 waiter parking 即遺失、匯出執行緒永久阻塞（OnEvent 失敗路徑更未持鎖、未記任何狀態，Destroyed 亦不通知不記錄），spurious wakeup 又把在途請求誤報失敗 · 自行修復 → PR #4298 merged（改於鎖內記錄明確 CompletionState、以述詞等待，Fixes #4296，maintainer Marc Alff 合併）· Issue 以 completed 關閉
open-telemetry/opentelemetry-cpp — Issue #4291 Issue · SocketAddr(char const *) 讀取未初始化位元組：host 複製進未初始化的 char[16] 並於固定索引截斷，凡 host 短於 15 字元 inet_pton 即讀到不定值，髒堆疊上把 1.2.3.4:80 靜默解析成 0.0.0.0:80 · 自行修復 → PR #4292 merged（Fixes #4291，同 PR 一併修 #4290，屬 ext/http 稽核 #4287）· Issue 以 completed 關閉
open-telemetry/opentelemetry-cpp — Issue #4290 Issue · SocketAddr(char const *) 在 Windows 越界寫：host 複製迴圈以 sizeof(buf)（位元組數）為界卻索引 WCHAR[200] 陣列，逾 200 字元的位址最多寫穿 400 位元組 · 自行修復 → PR #4292 merged（兩平台改用單一 inet_pton 解析器+valid/invalid 契約，Fixes #4290、#4291、屬 ext/http 稽核 #4287、maintainer Marc Alff 合併）· Issue 以 completed 關閉
kubernetes/kubernetes — Issue #140436 Issue · DRA structured allocator 在拒絕或回溯候選 device 時，未回滾已保留的 counters 與 constraints，造成 reserved-state 洩漏（sig/node · wg/device-management）· 自行修復 → PR #140431 merged 進 Kubernetes 核心（kind/bug · release-note）· Issue 以 completed 關閉
kubernetes/kubernetes — Issue #140434 Issue · DRA structured allocator 的 counter cache 以 pool 名稱為 key，導致不同 driver 的同名 pool 互相碰撞（sig/node · wg/device-management）· 自行修復 → PR #140435 merged 進 Kubernetes 核心（kind/bug · release-note）· Issue 以 completed 關閉
kubernetes/kubernetes — Issue #140433 Issue · DRA structured allocator 會把共用 counter 重複計算：當一個 allow-multiple 裝置只以 share ID 被記錄下來時，allocator 沒認出它已經是既存配置，於是又扣了一次同一個 counter（sig/node · wg/device-management）· 自行修復 → PR #140437 merged 進 Kubernetes 核心（kind/bug · release-note · sig/scheduling + sig/node）· Issue 以 completed 關閉
kubernetes/kubernetes — Issue #140441 Issue · consumable-capacity 的 roundUpRange 對大請求 int64 溢位：min+step*n 溢位成負，配額會計因此把一個實際上無法滿足的 device 判成可配置（sig/node · wg/device-management）· 自行修復 → PR #140442 merged 進 Kubernetes 核心（kind/bug · release-note）· Issue 以 completed 關閉
kubernetes/kubernetes — Issue #140472 Issue · 已修好的除零 panic 又回來了：#139653 報過、#139698 修過的 validRange.step 除零，在 step 為 2^64 的倍數時重新出現：那道守衛用的是精確的 Quantity.Sign()，但後續算術用的是超出 int64 就截斷的 Quantity.Value()，於是同一個值 Sign()==1 通過守衛、Value()==0 直接除零（sig/node · wg/device-management）· 自行修復 → PR #140666 merged 進 Kubernetes 核心（kind/bug · release-note）· Issue 以 completed 關閉
cncf-tags/container-device-interface — Issue #320 Issue · 單字元的 vendor 或 class 名稱會讓 parser slice-bounds panic：validateVendorOrClassName 對 name[1:len(name)-1] 沒有 len(name)==1 的守衛，於是算出低界大於高界的 name[1:0]；報告中指出兄弟函式 ValidateDeviceName 本來就有同一道守衛，因此是疏漏而非刻意拒絕 · 自行修復 → PR #321 merged · Issue 以 completed 關閉
intel/intel-resource-drivers-for-kubernetes — Issue #73 Issue · QAT kubelet plugin 的 Unprepare 在 multi-PF claim 時中途 return、per-device 反註冊 checkpoint，留下未釋放的 device（資源洩漏/生命週期缺陷） · 自行修復 → PR #74 merged（Fixes #73）· Issue 以 completed 關閉
kai-scheduler/KAI-Scheduler — Issue #1873 Issue · DRA GPU 數量加總溢位會低估佇列需求，擋掉本應成立的 GPU reclaim（受害的是同佇列裡被抵銷掉需求的正常工作負載，那個過大的反而沒事）· 自行修復 → PR #1874 merged · Issue 以 completed 關閉
kubernetes-sigs/dranet — Issue #255 Issue · MergeNetworkConfig 只用 destination 去重，導致同一 destination 但不同 routing table 的路由被丟掉 · 自行修復 → PR #256 merged（kind/bug · release-note，Fixes #255）· Issue 以 completed 關閉
kubernetes-sigs/dranet — Issue #253 Issue · route/rule 驗證放行 IPv4 與 IPv6 混用的設定，但 kernel 實際會拒絕（驗證層與核心行為不一致）· 自行修復 → PR #254 merged（kind/bug · release-note，Fixes #253）· Issue 以 completed 關閉
kubernetes-sigs/dranet — Issue #250 Issue · 診斷 relocated kubelet --root-dir 致 dranet 註冊失敗（硬編 /var/lib/kubelet plugin 目錄），並與相似 #19 區隔 · 自行修復 → PR #251 merged
kubernetes-sigs/kueue — Issue #12896 Issue · DRA device count 溢位導致超額 Workload 被 admit、並汙染 ClusterQueue 已用配額 · 自行修復 → PR #12897 merged · Issue 以 completed 關閉
kubernetes-sigs/kueue — Issue #12908 Issue · counter-charge 乘法溢位（#12896 的 follow-up，再揪出配額計算的乘法溢位）· 自行修復 → PR #12909 merged · Issue 以 completed 關閉
ocudu/ocudu — Work Item #577（GitLab） Issue · NTN 的 --k_mac 是唯一沒有 CLI 範圍檢查的參數（3GPP kmac-r17 定義為 INTEGER 1..512；其餘 NTN CLI 參數如 cell_specific_koffset、ta_common 皆有 CLI::Range）· 自行修復 → MR !1045 merged 進 dev（Fixes #577）· Work item 已結案
ocudu/ocudu — Work Item #579（GitLab） Issue · NTN 的 ta_common + ta_common_offset 之和可溢出 ASN.1 taCommon-r17 合法範圍（0..66485757）且無任何驗證（3GPP R17 NTN 定時提前）· 自行修復 → MR !1047 merged 進 dev（校驗總和落在範圍內，Fixes #579）· Work item 已結案
ocudu/ocudu — Work Item #658（GitLab） Issue · MAC · sib_pdu_assembler 在 remove-then-re-add 未變內容後把 SI 訊息廣播成全 0（encoder 向量每次 reconfig 縮放、content cache 只單向增長 → 兩向量生命週期不一致致 null encoder）· 自行修復 → MR !1162 merged 進 dev（修正 SI buffer 快取生命週期並補回歸測試，Closes #658）· Work item 已結案
kubernetes-sigs/cluster-api-provider-aws — Issue #6129 Issue · 把既有的 spec.secondaryControlPlaneLoadBalancer 設為 null 移除時，AWSCluster 的 validating webhook 以 nil pointer dereference panic（ValidateUpdate 只在新舊值皆為 nil 時跳過該組，oldlb != nil、newlb == nil 因而走進既有 LB 分支解參考 newlb）· 自行修復 → PR #6130 merged（kind/bug · release-note，改為明確拒絕移除並回傳驗證錯誤）· Issue 以 completed 關閉
volcano-sh/volcano — Issue #5620 Issue · capacity plugin 的 DRA 配額會計直接在原生 int64 上加總使用者可控的 device count，溢位後把超額 Workload 判成可配置（與已 merged 的 kueue #12896 同一 int64 溢位家族）· 自行修復 → PR #5621 merged（新建 SaturatingAdd/Mul · CNCF Incubating）；殘餘的 addDRAResource 原生累加路徑由 #5625 補上（維護者 JesseStutler 三輪推回後只留使用者真能觸發的溢位那一半，2026-09-16 合併，release-1.15 backport #5983 同日合併）· Issue 以 completed 關閉
akhenakh/sgp4 — Issue #10 Issue · FindPosition 對 deep-space 軌道靜默回傳 err == nil 的錯誤結果（SGP4/SDP4 邊界未拒絕）· 自行修復 → PR #11 merged（拒絕 deep-space 靜默錯誤；另 #12 Vallado SGP4-VER 正典驗證）· Issue 以 completed 關閉
kubevirt/kubevirt — Issue #18541 Issue · vGPU 的 countConfiguredMDEVRamFBs 把「present 但 enabled 未設」的 ramFB 當成關閉，與 SetDefaults_FeatureState（未設補 true）矛盾，導致 VM/VMIRS 接受但 VMI 被拒 · 自行修復 → PR #18542 merged（kind/bug · release-note · CNCF Incubating）· Issue 以 completed 關閉
kubernetes-sigs/dra-driver-cpu — Issue #253 Issue · dracpu 只處理 SIGINT、不處理 SIGTERM，正常 Pod 終止（kubelet 送 SIGTERM）時關閉清理不會執行 · 自行修復 → PR #257 merged（攔截 SIGTERM 讓 graceful shutdown 正常執行）· Issue 以 completed 關閉

C · 我回報、上游據以修復並合併，或仍在審查中

系統性的成群缺陷收在 Audits。完整回報清單（含未逐一列出的長尾）見 GitHub。

zephyrproject-rtos/zephyr — i2s/dma 跨 vendor 稽核（#120493/#120501/#120503/#120504） Issue（Bug 群 · drivers · 2026-09-28 回報）· 同一組資源歸還與 API 契約的檢查，換四家 SoC 再走一次：nrf_tdm 的 get_next_rx_buffer() 先從 slab 配走 RX block 才做 dmm_buffer_in_prepare()，prepare 失敗就直接返回、兩個呼叫端都不還，而 start_transfer() 的錯誤路徑只在 p_rx_buffer 有值時才還；tdm_nrf_write() 在 TX 側同形，dmm_buffer_out_prepare() 成功之後 k_msgq_put() 失敗就漏掉（#120493）；i2s.h 把 config_get 列為必備 op、i2s_config_get() 不做 NULL 檢查就呼叫，litex 與 max32 兩個 driver 的 API struct 沒有填它，i2s_buf_write() 與 i2s_buf_read() 也走這條（#120501）；mcux_lpc 的 dma_stop() 不檢查 channel ID，沒經過 dma_config() 的 channel 其 channel_index[] 還是 -1，整段操作於是落在 channel_data[-1]，DMA_AbortTransfer() 用的是那裡存的基底位址與 channel 號、DMA_SetCallback() 直接寫到界外，而 i2s_mcux_flexcomm.c 的 DROP 走得到（#120503）；siwx91x 的 DROP 每次都放一個 runtime PM reference，對應的 get 在 START、而 DMA 回呼在串流停止時已經放過，於是 START 之前或停止之後的 DROP 會在使用計數為 0 時再放一次，開了 CONFIG_PM_DEVICE_RUNTIME_ASYNC 就印 Unbalanced suspend（#120504）· 四則都附程式碼路徑與影響分級，回報中、待修
NVIDIA/aerial-cuda-accelerated-ran — 移植到 DGX Spark 時回報的問題（#34/#36/#37/#38/#41/#45） Issue（Bug 群 · cuPHY／testMAC／fh-driver · 2026-04-27～05-11 回報）· 把 GPU 加速的 5G RAN 搬到 aarch64 的 DGX Spark，一路撞到的平台假設：cuPHY CRC 的 simple API 路徑沒有初始化 desc.schUserIdxs，異質 TB 的 CRC 測試在 sm_121 上失敗，受影響的原始碼在 25.3.2 與 26.1.0 之間一個位元組都沒變（#34）；CRCTest.UplinkPuschWithTiming 期待回傳 0，CRC_GPU_UPLINK_PUSCH_TEST 卻以 1 表示成功（#36）；testMAC 的 run_l2sa.sh 寫死 x86_64-linux-gnu 的函式庫路徑，SCF L2 Adapter Standalone 在 aarch64 上起不來，留言者建議的 BUILD=build.aarch64 解的是另一個預設值（#37）；genPerfTVs.py 傳入不存在的 'AllChannels'，應為 'allChannels'，F08 的 perf test vector 產生不出來（#38）；fh-driver 把 NIC link-down 當成 FATAL（nic.cpp:609），沒接線時 ru_emulator 與 cuphycontroller 都起不來（#41），接著請求為 cable-on 自迴路加一個可恢復的 UL pipeline 逾時設定（#45） · 移植過程寫成預印本 Cross-Layer Diagnostics for Operator-Side Platform Porting of GPU-Accelerated 5G RAN · 六則仍開，2026-09-29 查 main，#37 與 #38 的問題仍在
zephyrproject-rtos/zephyr — Issue #115722 Issue（Bug · ESP32 DMA · 社群修復）· PM policy lock 是整個控制器共用的一個旗標，最先結束的傳輸就替其他人放掉：driver 以單一旗標記錄有沒有取得 PM policy lock，多個 channel 同時在跑時，第一個結束的把鎖還掉，其餘還在傳輸的 channel 就失去那個保護 · 2026-08-09 回報 · 由 raffarost 以 #117706 修復（把旗標移進 channel，2026-09-05 合併，+11/-21），屬社群修復 · 2026-09-28 自行以 completed 關閉並註明修在哪一支
我回報、由社群其他貢獻者修復並合併（RocketPy 7 則、kueue 14 則、opentelemetry-cpp 2 則、HAMi-DRA 1 則、otel-collector-contrib 1 則、test-infra 1 則、scheduler-library 1 則、dra-driver-cpu 1 則、dra-driver-google-tpu 3 則、dra-driver-spyre 1 則、spinifex 1 則、KAI-Scheduler 1 則、taiwan-md 1 則） Issue（回報 → 社群修復）· 我找出並回報、由專案其他人提 PR 修好合併的缺陷，即「找到 bug、促成上游修復」的貢獻，修正非本人提交/FF：RocketPy parachute trigger 每時間節點評估兩次（#1086）、coverage 六分之五 matrix 報告被丟棄（#1088）、parachute pressure noise 不在 Monte Carlo seed tree 內（#1091）、MonteCarlo 輸入輸出非原子寫入（#1110）、dict_generator 連 initial_solution 這種非隨機的 tuple 也一併抽樣（#1109，以 #1122 修）、MonteCarlo 每次模擬把 flight dictionary 抽三次導致記錄下來的輸入與實際飛行不符（#1090，以 #1126 修），以上由 thatrandomasiandev 修；parachute 拒絕 numpy 整數 trigger 卻接受 float（#1106，abhi-0203 修）。kueue pod_scheduling_gate_removal metric 缺 replica_role label（#14457，gangadhar-res 修）、負的 pod_scheduling_gate_removal_seconds 觀測值未夾為零（#14456，Antrikshgwal 以 #14474 修）、MPIJob ValidateUpdate 排序一個它並不擁有的 slice（#14476，abdelrahmanmagdii 修）、KubeRay presubmit 測到 raymini 版本更新後過期的 image（#14518，維護者 tenzen-y 以 #14523 修）、DRA extended-resource resolver 把負的 request 保留成負的 logical charge（#14216，pujitha24 以 #14367 修）。opentelemetry-collector-contrib 的 prometheusremotewrite receiver 把長度不對的 exemplar trace／span ID 補零或截斷，而不是拒收（#50547，arcusbuilds 以 #50576 改成不再補零截斷；同一個 receiver 也是本人 #50292 的稽核範圍）；kueue 的 quota-reserved Workload 無法隨擁有者離開 WorkloadPriorityClass、重試又不會停（#14482，gangadhar-res 以 #14565 跳過 API server 會拒絕的 priority transition 來修）；dra-driver-google-tpu 的 AcceleratorGen 接受不支援的 TPU 世代（#32，yindia 以 #48 直接拒絕修）；另 ibm-aiu/dra-driver-spyre 的 prepareDevices 拿別 driver 的 allocation result 去對 Spyre 裝置 map 解析、讓多 driver 的 claim 整包失敗（#59，該 repo 現階段只收 collaborator 的 PR，故由維護者 sunya-ch 依報告自行實作 #65 的 foreign driver 過濾）；另 kubernetes-sigs/dra-driver-google-tpu 的 ApplyNetworkSettings 文件說會把寫入值讀回驗證，實作只把讀回值 log 出來就丟掉、從不比對（#33，yindia 以 #46 改成讀回不符時發 warning）；另 kubernetes-sigs/dra-driver-cpu 的 extraArgs 可覆蓋 --bind-address 卻不同步更新 health probe（#256，維護者 fmuyassarov 以 #294 把 extraArgs 從 helm chart 移除來解決）；另 kubernetes-sigs/scheduler-library 的過期 ClusterSnapshot wrapper 可以改到共享 snapshot、而下一次 refresh 不會察覺（#9，維護者 brejman 以 #19 修；本人自提的 #11 於其合併後撤回）；另 kubernetes/test-infra 的 DinD 委派讓 Go 的 container-aware GOMAXPROCS 看不到實際生效的祖先 CPU quota（#37727，stmcginnis 以 #37733 修）；kueue 的 WorkloadPriorityClass sweep 會把整份成員名單序列寫完、中途從不檢查取消（#13982，pujitha24 以 #14737 加上界並讓它可取消來修）；opentelemetry-cpp 的 SocketAddr 整數建構子對超出範圍的 port 靜默 wrap（#4305，維護者 marcalff 以 #4500 把 ext/http/server 的 port 改成 uint16_t 修）；opentelemetry-cpp 的 Elasticsearch exporter 收到含非法 UTF-8 的 log record 會直接讓整個 process abort（#4439，om7057 以 #4501 修）；kueue 的 prebuilt Workload 等價判斷漏掉 pod-level resources 與 ResourceClaims（#14390，pujitha24 以 #14436 把兩者納入 PodSet 相等性比較來修）；kueue 的 worker cluster 端 WorkloadPriorityClass 會覆蓋 MultiKueue 在該處建立的 Workload 優先權（#13929，本人自提的 #14116 未經審查即關閉，由 weizhoublue 的 #14963 修）；kueue 的 pod-index-offset annotation 有寫在文件上的合約（webhook 設定、TAS ungater 據以把 Pod index 對到 topology，指定 podset-group-name 時不設），但 MPIJob 上沒有任何東西在執行它：mutating webhook 只在 CREATE 寫、validating webhook 的 validateTopologyRequest 從不看這個 annotation（#14475，adibmbrk 以 #14485 在 MPIJob 與 LeaderWorkerSet 上補上驗證來修，本人亦審過該 PR）；kueue 開啟 KueueDRAIntegration 時，handleDRA 先算好 workload 的 DRA 資源、用 WithPreprocessedDRAResources 交給佇列，但 Reconcile 的 backoff 重排路徑把 workload 加回佇列時沒帶那個選項，佇列裡的 Info 從原始 pod spec 重建：DRA 邏輯資源掉了、本該被 DRA 取代的 extended resource 留著（#13930，vibhordubey333 以 #13967 修）。這支他審了四次：8/10 建議只做窄修、把重構留給 sohankunkerkar 的 #14035，並在 17 分鐘後更正自己的第二點；8/24 指出要改的是 waitingForBackoff 守衛而非傳遞；9/11 改跑 DRA integration suite 重審（unit 案例從空佇列起跑、真實路徑不是），抓到 PR head 上帶 ResourceClaimTemplate 的 workload 在 backoff 之後根本回不來，40 秒後仍在 inadmissibleWorkloads，比 main 的「回來但資源錯」更糟，並自承拿掉守衛是他 8/24 的建議；維護者 sohankunkerkar 確認「without the fix this PR makes things worse for users」，作者當晚以 00fc730 改成在 PushOrUpdate 比對 RequeueState，sohankunkerkar /lgtm /approve 並要求 cherry-pick 到 release-0.18 與 0.19，2026-09-12 合併；兩支 cherry-pick 自動套用失敗，待手動）；kueue 的 excludeResourcePrefixes 先於 transformations 套用，一個 input 落在被排除前綴底下的 transformation 就永遠不會觸發、它的 outputs 靜默消失，沒有錯誤、沒有 condition、沒有 log；KEP-2937 的 graduation criteria 寫了要驗這種重疊，卻在 2025-09-08 沒帶著它就升 GA。回報時指出：照 KEP 寫檢查會把官方文件 administer_cluster_quotas.md 兩節連著看的設定判成錯、而設定錯誤是 os.Exit(1)，升級後叢集會起不來，所以三種答案（驗重疊、先跑 transformation 再過濾、維持行為只寫文件）該由這個欄位的 owner 挑，沒有先送 patch（#14204，2026-08-12 回報；與自報的 #14007 是兩件事，那邊 transformation 仍會跑、只是 multiplyBy 變成 1）。henry3260 選了驗重疊，以 #15926 在 validateResourceTransformations 報設定錯誤（+71/-0，release note 標 ACTION REQUIRED：升級前得先拿掉那個 transformation 或收窄前綴，否則 Kueue 起不來）；他問要不要 feature gate，kannon92 說不用、/lgtm /approve，mimowo 補一句「要 cherry-pick 就得有 gate，我只往前滾」後 approve，milestone v0.20，2026-09-22 合併並關閉；#14393：NeedsDRAReconcile 讀的是每個容器的 Resources.Requests，而每個呼叫端問的都是還沒經過 AdjustResources 的 Workload，request 正是在那裡才第一次出現（LimitRange 的 defaultRequest、把 limit 複製成 request），於是只在 limits 提到 DRA-backed extended resource 的 Workload 會被判定為不需要前處理，資源以原名進 quota、沒有 DeviceClass 解析也沒有邏輯計費（2026-08-13 回報，附 main 上量到的三行對照）；#15284（#14964 的一部分，非本人）把判斷改到帳務所用的同一份有效視圖上，bolubo 9/24 以原本的重現步驟複驗兩種輸入都已正確，我當日關閉。另一則 #14255：直接寫出來的 Workload 可以帶一個比它涵蓋的容器還小的 pod-level request，而 Kueue 收較小的那個。apiserver 對 Pod 會用 validatePodResourceConsistency 擋下這個形狀，但 Workload 不是 Pod，webhook 各自驗容器與 pod-level 兩份清單、從不互相比較，於是一個容器要 8 顆 CPU 的 PodSet 可以靠 pod-level 的 0 保留到零（2026-08-12 回報）；Dasmat13 以 #16047 修（+174/-5、5 檔），mimowo lgtm、approve 並要求回移 0.19 與 0.18，兩支自動 cherry-pick 都套不上去、改由作者手動準備，2026-09-23 合併並關閉；Project-HAMi/HAMi-DRA 把 annotation 值未加引號、未去空白就串進 CEL selector（#73，moezdil 以 #91 加上引號與 trim 修；HAMi 為 CNCF Incubating）；dra-driver-google-tpu 的 util.go 不擋非正的 topology／chip-count，也沒防 chip-count 相乘溢位（#23，yindia 以 #51 直接拒絕非正值來修；該 repo 三則回報皆由 yindia 修好）；另 mulgadc/spinifex 的 insomniacslk/dhcp pin 早於 nclient4 ReadFrom 修復、我回報後由維護者 juliansommer 修（#803）；kai-scheduler/KAI-Scheduler 的 --enable-quota-validation 父子佇列配額檢查把子佇列的 quota 原樣相加、從不把 -1（unlimited）當無上限，一個 unlimited 的子佇列反而把總和拉低，蓋掉真正的超額（父 10、子 A 為 -1、子 B 為 5，算出 4 < 10 就不警告；審自己的 #1810 時發現、刻意不併進去，因為 #1883 正在改寫同兩個函式，2026-07-12 回報 #1881，SiorMeir 當日指派給我）。兩個月後 eladb 以 #2167 修：新增 -1-aware 的 addQuota／quotaExceeds、unlimited 印成 unlimited，順帶把 create 路徑只加總 CPU、不加總 GPU 與記憶體的 #1923 一起修掉，enoodle 與 itsomri approve，2026-09-16 合併並關閉兩則 issue；同 repo 自報的 #1880 與 #1894 仍開；frank890417/taiwan-md（開源、給 AI 讀的台灣知識庫，1,185 stars）的〈台灣災難醫療體系〉把「921 若體制完善約 500 人本可救活」寫進制度起源的敘事、再讓它催生 2000 年《災害防救法》，我指出這是 AI 幻覺：500 這個數字來自 1995 年阪神淡路大震災、催生的是日本 2005 年的 DMAT，文章自己引的急診醫學會原文沒有這個數字（#1752，2026-09-19 回報）；維護者 frank890417 不到四小時就確認「數字是真的，槽位是錯的」，以 commit a17bb572e 改掉小標與整段、關閉
kubernetes/kubernetes — 私下回報給 Security Response Committee（2026-09-12，待回覆） Issue（Security · sig/node · user namespaces）· user namespaces 開啟時，kubelet 先查「kubelet」帳號存不存在、再跑 getsubids 決定 pod 的 host ID 範圍，而帳號查詢看不出目錄服務斷線：存放帳號的 NSS backend（sss、ldap）不可用時查詢回「no such user」，kubelet 就用預設池 65536 到 4294967295，不是管理員為該帳號設的範圍，唯一痕跡是一行 V(5) log「user not found, using default mappings」。用自製的 NSS module（回 NSS_STATUS_UNAVAIL 與 TRYAGAIN）在私有 mount namespace 裡綁 nsswitch.conf，量了六種 layout：getent 六種全部 exit 2、從不回報 backend 不可用；cgo 的 os/user.Lookup 只在 nsswitch 停在失敗服務時才回錯。所以 1.33 到 1.37（cgo 建置）在常見的 files sss layout 下 fail open，只在 [UNAVAIL=return] 或 backend-only 時 fail closed；master 自 #135870 改走 getent 起，每一種 layout 都 fail open，靜態化把唯一能回報 backend 錯誤的路徑也拿掉了。影響：目錄專用的 kubelet 帳號在啟動時遇到目錄斷線，pod 被靜默對進 65536 起的區間（目錄使用者的 UID 通常住在這），目錄回來後 kubelet 重啟時 recordPodMappings 拒絕範圍外的對映而起不來。前提是 kubelet 帳號不在 /etc/passwd 且啟動時 backend 不可用；回報明說是 fail-open 行為，不是已示範的利用。#141970、#141971、#142027、shadow#1738 四個公開項目都沒提到斷線情境；附三個修法方向並表明可測 · 2026-09-12 04:02 寄出
open-telemetry/opentelemetry-cpp — Issue #4625 Issue（Build · 對外表面 · help wanted · triage/accepted）· Bazel 的 //ext:headers 把 CMake 安裝刻意排除的六個標頭一併露出來：CMake 只裝 http_client.h 等四個、整個排掉 detail 與 server 目錄，Bazel 用 glob 十個全收；一個只依賴 //api 與 //ext:headers 的探針 package 對 http_server.h 與 http_operation_curl.h 都建得過。於是 curl 的 Session 與 HttpOperation 版面對 Bazel 使用者是碰得到的，改動就是 break，安裝樹卻說它們不是表面。兩條路（把 Bazel 目標收成那四個、其餘給樹內測試與範例另立目標；或反過來把 CMake 放寬到跟 glob 一樣，那會跟 ext/CMakeLists.txt 裡寫好的理由打架）都不是我該決定的；自己的 #4332 把 server 標頭搬走只解掉六個裡的兩個，#4458 的待決事項記著同一個分歧 · 做 #4618 時想知道把 HttpOperation 的成員改成 atomic 算不算 ABI 問題而找到 · 2026-09-22 回報，半小時後維護者 dbarker 標 triage/accepted 與 help wanted
golang/go — Issue #81776 Issue（Bug · runtime · 待處理）· internal/runtime/cgroup 的 OpenCPU 在 cgroup v1 路徑上，第二個 open 失敗時漏關第一個描述子：先開 cpu.cfs_quota_us 再開 cpu.cfs_period_us，後者失敗就回 errSyscallFailed，沒有 linux.Close(quotaFD)。把同一個函式逐字抄進測試 package、換成真的 open 與 close，每失敗一次 /proc/self/fd 就多一筆；補上 close 之後量到的是零 · 自己把影響講小：runtime 只在啟動時開一次，留下的是整個行程生命週期的一個描述子，而那個行程的 cgroup-aware GOMAXPROCS 本來就關著；真實核心上這兩個檔在 kernel/sched/core.c 同一個 config 底下一起宣告，能踩到的只有原始碼註解已提到的 migration 與 rmdir 競態，或兩次 open 之間剛好用完描述子 · 表示可以送 CL · 2026-09-27 回報 · 這是繼 #81180 之後的第二則 Go runtime 回報
golang/go — Issue #81180 Issue（Bug · runtime · NeedsInvestigation · 待處理）· 容器感知的 GOMAXPROCS 只讀行程所在的那層 cgroup，上層有限制時會抓錯：父層 cpu.max = 200000 100000、葉層無限制，核心執行的是父層那個值，Go 卻退回 CPU affinity 的數量；同一組階層下，行程直接放在父層得到 GOMAXPROCS=2、放在葉層得到 5，開 containermaxprocs=1,updatemaxprocs=1 也還是 5，而葉層的 worker 實測只拿到約兩顆 CPU 的總執行時間。Go 1.25.12、1.26.5、1.27.0 三個版本都重現，且重現程式不依賴 Kubernetes · Go 團隊的 prattmic 回覆這是原始設計刻意的取捨（為了不重開檔案地定期更新，必須一直持有 cpu.max 的 FD，走整條階層就得持有多個），我接受那個前提，並把情境說清楚：一般容器讀宿主父層不在討論範圍，我碰到的是 Prow 的 bootstrap／kubekins runner 為了滿足 cgroup v2 的 no-internal-process 規則，自己把容器的 cgroup 再切一層給 Docker-in-Docker · 2026-08-28 回報，討論中
kubernetes/kubernetes — Issue #141624 Issue（Bug · sig/node · triage/accepted）· 約十九個 node-e2e 影像設定用 image_regex: ".*[^-cgroupsv1]$" 挑 cgroup v2，而那是 negated character class：它限制最後一個字元不能是 -cgroupsv1 裡的任何一個，所以 -cgroupsv1 是丟掉了，但任何以那些字元結尾的名字也一起丟，例如 ...v20260801 · pohly 把它轉給當初寫 test-infra#35723 的人，SergeyKanzhelev triage 並指派 harche · 自行修復 → PR #141626 merged（新增 image_exclude_regex，見 Ledger）· issue 仍開，因為那十九個設定要等 1.34 到 1.37 的 runner 都認得新欄位才能改
kubernetes/kubernetes — Issue #141635 Issue（Bug · sig/node · 待補資訊）· createGCEInstance 的就緒輪詢可以跑完而不回報任何錯誤：迴圈內的 instance, err := getGCEInstance(name) 是新宣告，外層的 instance 與 err 不受影響，而「VM 沒進 RUNNING」與「runtime service 不在」兩種錯誤都被指派給 _；迴圈結束後只檢查外層的 err，不檢查是否真的就緒 · 列出三種後果：provisioning 的錯誤訊息被吃掉、RUNNING 但 runtime 永遠起不來時靜默通過、以及後續步驟才用一個無關的錯誤失敗 · 2026-08-27 回報並自己 /assign，修正在 #141639（審查中；harche 9/26 指出 deadline 只殺直接子行程、CombinedOutput() 仍會等 pipe 關閉，9/29 再審時說就緒與錯誤的流程沒問題，另要求逾時切斷的那次嘗試不要蓋掉上一次的觀察；兩點 9/29 一併改完，WaitDelay 設 1 秒，各補一個測試）
kubernetes/kubernetes — Issue #141725 Issue（Bug · sig/storage · 待處理）· CSI driver 只回報這個 kubelet 不認得的健康狀態時，磁碟區看起來就是健康的：mapVolumeHealthStatus 丟掉不認得的 VolumeHealthErrorType、呼叫端 continue，整包都不認得時回傳空集合，而 volumehealth.manager 把空集合當成新的目標狀態去 SetPodVolumeHealth，於是把先前記錄的 Inaccessible 也抹掉。對 master 實測四種回覆列成表：[DEGRADED, 9999] 記到一筆（規格要的），[9999] 與 [UNKNOWN_VOLUME_HEALTH_TYPE] 都是零筆，與「沒有任何異常」無法區分；mapStorageHealthStatus 形狀相同，csinode.status.storageHealth 也一樣 · 2026-08-31 回報 · 社群的 Roaimkhan 以 #141743 接手修，我在上面留了 changes-requested（審查中）
kubernetes/kubernetes — Issue #142439 Issue（Bug · sig/node · priority/important-longterm · 待處理）· 開著 race detector 的 pull-kubernetes-kind-dra-all 在 kubelet 用的 cAdvisor 檔案系統統計裡抓到 write/write 競態，連套件收尾的 Log Check 也跟著紅：報告落在 GetVfsStats 的逾時返回與跑 statfs 的 goroutine 之間，六個結果各一份，出現在我自己那支 #142411 的 presubmit（149 過、2 敗）。追進相依之後在上游開了 google/cadvisor#3937 並附修正 #3938，這一則留在 Kubernetes 這側記錄它怎麼讓 job 變紅；另外說明為什麼 statfs 會超過兩秒：同一段時間整個 job 停頓，kubelet 的 log 行最多晚 42 秒才進 journal，但這一則不依賴那個停頓怎麼收場（見下一則）· 版本、kind 映像、containerd 與 race build 的旗標都附在 issue 裡 · 2026-09-26 回報，自己 /assign 並 cc release signal
kubernetes/kubernetes — Issue #142440 Flaking Test（sig-node · sig-testing · wg/device-management · 待處理）· pull-kubernetes-kind-dra-all 這支選擇性 presubmit 會整個停頓將近一分鐘，測試端看到的是 http2: client connection lost 與 TLS handshake 逾時：兩個失敗的 spec 都敗在 DeferCleanup 連不到 apiserver（刪 ServiceAccount 與 driver builder 各一），Log Check 也因為列 pod 兩次逾時而紅。到 2026-09-26 的兩週內 143 次完成的跑有 19 次撞到，其中 15 次在 #142127 合併之後；週期性的 ci-kind-dra-all 同期沒有出現 · 停頓期間的證據逐項列出：四個 kind 節點的 kubelet log 最多晚 42 秒、containerd 的 task delete context deadline exceeded、etcd 一次唯讀 apply 花 16.9 秒、controller-manager 與 scheduler 雙雙掉 lease 重啟，而 apiserver 與 etcd 沒有重啟、沒有 OOM、etcd 也沒記到慢速磁碟同步；對停頓本身只提出一個明說是猜測的解釋（pod 的 2 CPU 配額下的 CPU 飢餓），並附兩次更嚴重的同型跑（etcd apply 45 到 52 秒）· 2026-09-26 回報，待處理
google/cadvisor — Issue #3937 Issue（Bug · 併行 · kubelet 相依 · 待處理）· GetVfsStats 的逾時返回與跑 statfs 的 goroutine 對同一組具名回傳值各寫各的：goroutine 指派 err 與 total 到 inodesFree，逾時那條路在返回前把同一組變數寫成零值，兩邊沒有同步；有緩衝的 resultChan 只讓 goroutine 在呼叫端返回後不會卡住，管不到寫入順序 · 這是從 Kubernetes 開著 race detector 跑 kubelet 的 pull-kubernetes-kind-dra-all 追出來的：9/21 到 9/26 共八次、六個結果各一份報告，最近一次在我自己那支 #142411 的 presubhit 上 · 2026-09-26 回報 · 自行修復 → PR #3938（goroutine 改填區域 result 再交給 channel，不碰呼叫端變數；syscall 與逾時改成可替換的 package 變數以便測試，+109/-11、2 檔，審查中）· Kubernetes 那側的記錄見上一則 #142439
wmnsk/go-pfcp — Issue #145 Issue（Bug 群 · 5G 核心 PFCP · 待處理）· 一批 IE 解析器在短或畸形 payload 上 panic，或在合法輸入上吃掉欄位：對每一種已定義的 IE 型別、用短的隨機 payload 呼叫 *ie.IE 每一個不帶參數的匯出方法，再把幾個 New* 建出來的 IE 送回各自的 parser 來回跑，逐一列出結果。最能從線上到達的是 PFD Contents：一個 message.Parse 收得下的 PFD Management Request，讀它的 PFD contents 就 slice bounds out of range [:65539] with capacity 6；其餘包括 Flow Information、Downlink Data Service Information（有 QFI 沒有 PPI，正是某個 New* 建出來的形狀）、Remote GTP-U Peer、UP IP Resource Information、Outer Header Creation 等 · 2026-09-26 回報 · 自行修復 → PR #146（+818/-53、24 檔、11 commits，審查中）
cri-o/cri-o — Issue #10375 Issue（Bug · 容器執行期 · CNCF Graduated · 待處理）· 沙箱裡若有一個「建立了但從沒啟動」的容器，StopPodSandbox 會把整個停止逾時等好等滿：停止時對它送 SIGTERM，容器裡沒有東西能反應，CRI-O 要等到逾時才 kill；配上 kubelet 兩分鐘的請求期限，就是每個沙箱 118 秒。用 crictl 在 CRI-O 1.36.6 上以三行重現（runp、create、不 start，然後 stopp 花 118.06 秒），同一個沙箱在容器已啟動時是 0.13 秒，containerd 2.4.0 停一個只建立過的容器是 0.16 秒 · 這是從 Kubernetes CI 追回來的：sudharshanibm 回報的 #142404 那四次 ci-node-crio-dra 失敗，都是 kubelet 重啟落在 CreateContainer 還在飛的時候，CRI-O 記下 CreateCtr: context was either canceled 卻仍把容器掛在沙箱上（s.addContainer 在檢查 context 之前就做了），新的 kubelet 再建一個，後來的 StopPodSandbox 四次都是 118 到 119 秒；另外自己用「在 create 開始 20 毫秒後殺掉 crictl」也重現了取消版本 · 附上四個 prow run 編號、兩邊的版本與作業系統，並指出 internal/oci/runtime_oci.go 的 StopContainer 對已停止與暫停的容器都有早退路徑，只有「已建立」的走一般的訊號與 WaitOnStopTimeout · 2026-09-26 回報，待維護者裁決
submariner-io/submariner-operator — Issue #4272 Issue（Bug · CNCF Sandbox · 待處理）· Corefile 只要有一行提到 #lighthouse-start，從那行到檔案結尾就會被截掉：移除既有 Lighthouse 區段的迴圈以 strings.Contains 逐行比對，所以檔案自己的註解、或被手動編輯弄丟結束標記的情況，都會讓剩下的內容整段消失，新區段再接到殘骸前面。預設目標是 kube-system/coredns 的 Corefile，*-coredns 後備與 MicroShift 的 openshift-dns/dns-default 走同一個函式；附一支只複製那個迴圈就能跑的重現程式 · 2026-09-25 回報 · 自行修復 → PR #4273（標記必須是整行的第一個 token、後接空白或行尾；不成對時回錯誤、整個 ConfigMap 不動，+193/-24、3 檔，審查中）
cncf-tags/container-device-interface — Issue #364 Issue（Bug · 併行 · CNCF）· NewCache 與它自己啟動的 Spec 目錄監看器競態：newCache 不持 c.mu 就呼叫 configure，後者先啟動監看器、再呼叫 refresh，而 refresh 自己不鎖就寫三個欄位；其他每一條進到 refresh 的路徑都先鎖了，只有建構子沒有。附一個只依賴這個函式庫的最小重現（一邊迴圈寫 Spec 檔、一邊建二十個 cache）：v1.1.0 通過、v1.1.1 三個 race block、main 也一樣 · 這是 dra-driver-sriov #175 往上游追出來的根因，回報當晚一併送出修正 #365（把鎖包回整段 configure，回到 v1.1.0 的樣子；新測試未修時十跑十紅、修後十跑十綠）· 2026-09-25 回報，審查中
k8snetworkplumbingwg/dra-driver-sriov — Issue #175 Issue（Bug · 相依升級 · Network Plumbing WG · 待處理）· go test -race 自 container-device-interface v1.1.0 升到 v1.1.1 之後在 pkg/cdi 與 pkg/devicestate 必報競態：競態兩端都在相依裡、同一個 NewCache 呼叫上。refresh() 會寫 c.specs、c.devices 與 c.errors 而自己不取鎖，所以呼叫端得負責；監看路徑與匯出的 Configure 都有取，建構路徑沒有：newCache 呼叫 configure，後者先啟動監看 goroutine、再在沒有持鎖的情況下呼叫 refresh，這個空窗裡只要來一個 fsnotify 事件，goroutine 就會在建構子還在刷新時再刷一次。v1.1.0 是把鎖包在整段 configure 外面的，v1.1.1 拿掉了鎖卻留著 goroutine，升級的那個 commit 是 618a76f · 在 main 上五跑五中；兩組只改一件事的對照：go.mod 釘回 v1.1.0 五跑零中、改用 WithAutoRefresh(false) 五跑零中 · 明講影響範圍：make test 與 make test-coverage 都不帶 -race，所以 CI 不會紅，這是本機跑 race detector 才會遇到的；driver 啟動時走同一個呼叫，但沒有看到它產出錯的結果，也不宣稱有 · 這個 repo 的 cache 只被寫、沒被讀，所以建議 WithAutoRefresh(false)，鎖則該回到上游那個函式庫 · 當晚就把它送上去了，見上方 container-device-interface #364 與 #365 · 2026-09-24 回報，待維護者裁決
kubernetes/kubernetes — Issue #142262 Flaking Test（sig-testing · sig-node · sig-release · priority/critical-urgent）· release-blocking 的 gce-cos-alphafeatures 兩支 job 自 9/17 起跑不完 kubetest 的 120 分鐘預算：master 61 跑 15 次 Timeout、1.37 分支 21 跑 7 次，91 個 e2e spec 幾乎每次全綠，只是時間用完在 teardown（15 次裡 14 次 91 Passed、1 次 ginkgo 在 113 分鐘被中斷）：以 v1.38 Release Signal Shadow 的身分開單並自己接 Release Signal 這一側的追蹤。同一個 commit、同一個 COS image 上一次 76 分鐘、一次 106 分鐘，差距全在 InPlacePodVerticalScaling 的 63 個 spec（57 對 86 分鐘，其他 28 個 spec 兩邊都 19 分鐘）；sibling job gci-gce-alpha-features 自 test-infra#37724 起有 180 分鐘預算，看得到這支看不到的尾巴：394 跑 0 次逾時，測試階段 p50 97、p99 119 分鐘。harche 當天 /triage accepted /priority critical-urgent；upodroid 表明不接受縮小測試範圍、也不先談拉長 timeout，要 SIG Node 先把 resize 測試改快；我把描述改成「下一步在測試端」、向 podresize 的 approver natasha41575 要人，再拆兩份 ginkgo report.json 找時間去哪：每跑 1,104 次 exec 進測試 pod 讀 cgroup 檔案，快跑 50 分鐘、慢跑 77 分鐘，其餘步驟兩邊都 7 到 10 分鐘；exec 的代價跟著 pod 的 CPU limit 走，沒 limit 的 0.1 到 0.3 秒一次、Guaranteed pod 2.9 到 4.5 秒，fixture 給的 25m 到 35m limit 讓 exec 起的 shell 每 100 ms 只分到 2.5 到 3.5 ms。所以變慢的不是 resize、是測試讀 cgroup 的方式，提議不經 exec 讀、或三個檔案併成一次 exec，SIG Node 要的話願意送 PR；kannon92 說 SIG Node 正把部分測試移往 slow lane。v1.38.0-alpha.1（9/23）擋不擋，決定權在 SIG Node、尚未定案 · 2026-09-21 開單、追蹤中
kubernetes/kubernetes — Issue #141829 → PR #141898 Issue（Bug · sig/node · DRA allocator）· AllocationMode: All 的請求遇到候選節點的 pool 正在更新或無效時，validateDeviceRequest（stable、incubating、experimental 三個變體同一段碼）回的是普通 fmt.Errorf，沒包 internal.ErrFailedAllocationOnNode；而 DynamicResources.Filter 只把那個 sentinel 對到該節點的 Unschedulable，其他 error 都變成 framework Error，findNodesThatPassFilters 的 checkNode 一看到就取消其餘所有節點的檢查：一個正在更新的 pool 讓整輪排程中斷 · divyanshuprakas-h 以 #141898 在三個 allocator 都包上 sentinel、保留原訊息、補回歸測試，pohly approve，2026-09-11 合併並關閉 · 2026-09-03 回報
shadow-maint/shadow — Issue #1738 Issue（Bug · Linux shadow-utils · 非 CNCF）· getsubids 在範圍指標為 NULL 時一律印 Error fetching ranges 並 exit 1，於是「帳號存在但沒有條目」「帳號不存在」「/etc/subuid 讀不到」三種情況在輸出上完全一樣（Debian 13、uidmap 4.17.4 實測）。file backend 對沒配到的情況回 count 0 加 NULL 陣列，NSS 查詢失敗回 -1；libsubid 的 enum subid_status 早有 SUBID_STATUS_UNKNOWN_USER 與 SUBID_STATUS_ERROR_CONN，但 subid_get_uid_ranges 只回 count 或負數，CLI 從沒看過那個差別。kubelet 就是分不出來的那個呼叫端，所以先走 getent、帳號存在但沒區間就拒絕啟動。回報裡把相鄰的 #1710、#1592（exit code 統一）、#1562（多個 NSS module）、#1685（回歸測試）都對上，並表明介面選定後可送 patch 與測試 · 共同維護者 alejandro-colomar 11 分鐘內回「Sounds reasonable」並 cc hallyn · 2026-09-12 新回報
nephio-project/nephio — Issue #1192 Issue（Bug · LFN／Nephio · 併行）· GetClient 在填入 singleton 的 goroutine 跑完之前，就把 singleton 交給呼叫端：singleInstance == nil 的檢查與後面的 lock.Lock() 之間，呼叫端拿到的是一個尚未初始化的 client · 2026-09-11 新回報
nephio-project/nephio — Issue #1193 Issue（Bug · LFN／Nephio · 分頁）· createToken 用零值選項呼叫 ListAccessTokens 判斷 token 是否已存在，那只回一頁：Gitea SDK 把零值 Page 當第 1 頁、PageSize 用伺服器預設 30，在 sandbox 釘的 gitea/gitea:1.19.3 上實測，帳號有 35 個 token 時只看得到 30 個，第 31 個之後的一律當不存在 · 2026-09-11 新回報
RocketPy-Team/RocketPy — Issue #1186 Issue（Bug · 6-DOF 運動方程式 · 非 CNCF）· u_dot_generalized 的質心力臂反號：v1 推導以乾質心為原點，要的是「乾質心→瞬時質心」與「乾質心→噴嘴出口」兩個向量，但它讀的 com_to_cdm_function 與 nozzle_to_cdm 依定義都是反方向（前者把自己的輸出標成「COM to CDM」，後者帶著前置負號），程式沒有取負就用，角加速度的力臂於是反號：一個施於乾質心的側向力會把火箭往 Newton-Euler 給的反方向俯仰。推出來的差是 2 · I⁻¹ · (r_CM × 氣動力)，推力軸向所以消掉；在 calisto 點火時 r_CM 0.132 m 對 0.261 m 力臂，回復力矩等於作用在約兩倍的距離上。附常質量、無重力無阻力、單一側向力的閉式重現 · 2026-08-25 回報；後來在唯一有實測值的 Defiance 2024 飛行上量到每個修正都把遠地點往量測值靠（0.709% → 0.693% → 0.648%），並自承一筆飛行的邊際太小、不能單獨當證據 · 自行修復 → PR #1196（兩處讀取取負、v_dot 一項換號、文件補原點宣告，七個單元測試各自盯住一半改動；+298/-26、7 檔，2026-09-16 送出、審查中）
cert-manager/cert-manager — Issue #9327 Issue（Bug · CNCF Graduated）· Ready=False、reason Failed 且沒有 status.failureTime 的 CertificateRequest，在私鑰被重用時永遠不會被換掉：metav1.Time.Before 對 nil receiver 回 false，request manager 的前次簽發檢查因此不會觸發；issuing controller 那側的守衛又要求 FailureTime != nil，於是每次簽發都走到 failIssueCertificate，Certificate 的 failedIssuanceAttempts 一路往上爬，而同一筆 request 原地不動 · 2026-09-10 回報；同日 kokhlo 以 #9328 依此提出修正（PR 內同樣點名 requestmanager_controller.go:284 與 issuing_controller.go:305 兩處守衛），審查中
nephio-project/nephio — Issue #1186 Issue（Bug · LFN／Nephio · focom-operator）· readTokenFromKubeconfig 自己手工解析 kubeconfig，直接取檔案裡的第一個 user，完全不看 current-context；kubeconfig 一旦有多組憑證，拿到的就是別人的 token · 2026-09-10 新回報
nephio-project/nephio — Issue #1187 Issue（Bug · LFN／Nephio · CI 可重現性）· default-gosec.mk 用兩條路挑工具：有 container runtime 時跑容器裡的 securego/gosec:latest，沒有時跑本機裝的那一版，於是同一份 Makefile 在不同機器上掃出不同結果 · 2026-09-10 新回報
kubernetes/kubernetes — Issue #141942 → kubernetes/test-infra PR #37840 Issue（Bug · test-infra · race job）· -race 需要 cgo，而 kube::golang::build_binaries_for_platform() 只把 KUBE_RACE 加到 non-static 與 .test 兩組，所以 kubelet 一旦進了 KUBE_STATIC_BINARIES，就完全帶不了 race instrumentation。報告裡把「哪些 job 真的從原始碼建 kubelet」逐一分清楚：dra-presubmit、dra-canary 與走 e2e-k8s.sh 的 kind job 會，指向 dl.k8s.io tarball 的 dra-ci 不會、加名字也不會有作用 · 應 dims 要求自 #135870 拆成獨立 issue 後，dims 以與 issue 同名的 test-infra#37840 實作並合併，Issue 以 completed 關閉；本人自提的 test-infra#37842 因而關閉
kubernetes/kubernetes — Issue #141940 → PR #135870 Issue（Bug · sig/node · 使用者命名空間）· os/user 在有無 cgo 之下行為不同，而 kubelet 靠它決定使用者命名空間拿到哪一段 subordinate ID。getKubeletMappings() 先呼叫 user.Lookup("kubelet")，遇到 UnknownUserError 就直接回內建預設區間、根本沒跑過 getsubids，於是同一份主機設定，kubelet 是不是用 cgo 編的，會決定它挑到不同的 ID 區間 · dims 的 #135870「Build kubelet as a static binary（CGO_ENABLED=0）」合併後，Issue 以 completed 關閉；該 PR 本人也審過。同批回報的 #141941 仍開著
kubernetes-sigs/kueue — Issue #14563 → PR #14822 Issue（Bug · area/dra）· deviceClassHandler 在 DeviceClass 新增、修改、刪除時會 requeue 受影響的 Workload，但它只找得到還沒取得 quota reservation 的那些：索引把已保留配額的 Workload 記在 QuotaReserved=True，剛好落在那份 List 之外，於是它們永遠收不到 DeviceClass 的變動 · 維護者討論後認定，要撤掉既有的 reservation 得知道 scheduler 當初是從哪個 DeviceClass 配出來的，controller 現在拿不到，屬 KEP Beta 的後續工作;yindia 以 #14822 補上回歸測試 TestDeviceClassHandlerSkipsReservedWorkloads、並把這個限制寫進 DRA KEP 的 Risks and Mitigations，Issue 隨之以 completed 關閉
cncf/prow-github-actions — Issue #101 → PR #107 Issue（Bug · CNCF）· README 的用法範例指向 @v2，但這個 repo 從來沒有 v2 tag，照著複製的人裝不起來 · mfahlandt 的 #107 把發布流程自動化（v* tag 觸發 release workflow，附 SBOM 與 provenance，+402/-0、5 檔），v2.0.0 因此存在；maintainer jeefy 在該 PR 合併的同一分鐘把 issue 以 completed 關閉。修正非本人提交。
vllm-project/vllm — Issue #53887 → PR #54201 Issue（Bug · AI serving · PyTorch Foundation／非 CNCF）· Qwen3.5 MTP 在 PP=1 載入時先配置並載入兩張完整 vocab table，之後才改與 target 共用，讓 27B INT4 target 在 24 GiB GPU 上多出 4.74 GiB loading peak 而 OOM：本人以 RTX 3090 重現、把 2.37 GiB allocation 追到 embed_tokens 與 lm_head，並更正初版報告只定位到其中一張的錯誤。Chishenzheng 接手送出 #54201，PP=1 不再建立兩個 temporary modules，實測 loading peak 25,826→20,974 MiB（-4,852 MiB）且 deterministic outputs 不變；2026-08-30 又有另一位使用者在 RTX 5090 重現並量化為約 15k 至 20k tokens 的 KV context。修正在審查中，非本人提交
kubernetes-sigs/external-dns — Issue #6683 Issue（Bug · AWS Route 53 · 2026-08-30 新回報）· --policy=upsert-only 的 record type change 被 Route 53 拒絕後，會留下沒有對應 A/AAAA record 的 ownership TXT：external-dns 先送 a-/aaaa- TXT，下一個 batch 才送 A/AAAA ALIAS；舊 CNAME 未刪使第二批失敗，第一批卻已提交，reconcile 因而永不收斂。#6640 的完整 registry/provider loop 測試可到達該狀態，但刻意不把未解決行為鎖成正確結果。尚無接手者或修正
zephyrproject-rtos/zephyr — Issue #114739 Issue（Bug · 嵌入式/顯示驅動）· MIPI DBI Type A（6800）模式在 dcnano_lcdif 永遠對不到輸出格式：mcux_dcnano_lcdif_dbi_configure() 的 format_map[] 拿 Type A 常數當寬度 key，任何 Type A（6800）模式都解析不出 output format · 由 maintainer（NXP）以 PR #115197 修復、Issue 以 completed 關閉
kubernetes-sigs/kueue — Issue #13933 Issue（Docs · RBAC）· external integration 指南給的是 core/v1 Event RBAC，但 jobframework 實際透過 events.k8s.io 記事件：照指南設 RBAC 的自訂整合會因權限對不上而記不了事件 · 由社群 PR #14021 修復、Issue 以 completed 關閉
kubernetes-sigs/kueue — Issue #13987 Issue（Docs · KEP 一致性）· KEP-2941 寫 DeviceClass mapping 唯一性為絕對、把放寬列為未來工作，但 validator 早已實作放寬：文件與實作不一致、誤導讀者 · 由社群 PR #13993 修復、Issue 以 completed 關閉
kubernetes-sigs/cluster-autoscaler — Issue #37 Issue（Bug · kind/bug · wg/device-management · needs-triage）· DRA Provider snapshot 直接共用 informer 的 ResourceClaim 指標，改 snapshot 會寫進 informer 快取：Provider.Snapshot 從 ResourceClaim lister 取指標後直接存進 snapshot（沒深拷貝），但 informer lister 回傳的物件是共享、契約上須當唯讀。未 fork 的 snapshot 其 base layer 即 top layer，ensureClaimWritable 因而把 base claim 當成已可寫、原封回傳 → 對 snapshot 的任何修改直接改到 informer 快取裡的共享 *ResourceClaim、污染其他 consumer 與後續 reconcile。應在放入 snapshot 前深拷貝 · 2026-08-08 回報；magic-peach 9/4 以 #104 在 provider 端深拷貝（+31/-1），Choraden 9/7 lgtm；我 9/17 從另一側送出 #124（在 ensureClaimWritable 於 base layer 為當前層時複製），發現 #104 修的是同一件事、40 分鐘後自行關閉讓路，並在 #104 上留下 RunOnce 實測（main 上 informer 的 claim 跑完迴圈多了一筆 reservation、#104 上是空的）與「slice 與 class 不必拷貝，snapshot 從不寫它們」的回答 · #104 於 9/18 經我覆核（作者補上 Fixes #37，我另把 CI benchstat 上 ScaleUpDRA 的 +3% 指為 runner 漂移：同一輪非 DRA 的 ScaleUp 也動了 +2%，而那條路根本不執行這段程式），但 2026-09-22 維護者 skitt 引用 sig-autoscaling 的 Slack 討論串，以 /close 一次關掉含 #104 在內的五支 PR，未合併；同 repo 自報的 #33（Pod 兩次引用同一 ResourceClaim 時 Revert 漏掉 mutation，8/7 回報）由 magic-peach 以 #105 修，我在上面把兩個 alias 的 Pod 推過 Reserve、Unreserve 與 shared-claim 三條路徑，main 上三條都漏、該 head 都乾淨，同一批一併被關 · 兩則 issue 因此仍開
kubernetes-sigs/karpenter — Issue #3221 Issue（Bug · needs-triage）· DRA device-allocation controller 把 admin-access 結果當一般 occupancy 計入：Karpenter 把已配置 ResourceClaim 的 DeviceRequestAllocationResult 依 (driver, pool, device) 摺進 per-device occupancy（獨佔或已耗用容量），但 contributionsForResults（pkg/controllers/dynamicresources/deviceallocation/controller.go）從頭到尾沒讀 result.AdminAccess。admin-access 配置（feature gate DRAAdminAccess）依 API 定義「無視所有一般 claim 的存取模式與資源配置」、只授權存取而不保留或耗用裝置 → 卻被當成一般佔用累加，controller 因而高估裝置 occupancy、可能誤判節點已滿而做出錯誤的 provisioning/consolidation 決策 · 回報中、待修（needs-triage）
kubernetes-sigs/kueue — Issue #13820 Issue（Bug · area/integrations）· UpdateWorkloadPriority 每個 Workload 各自 resolve WorkloadPriorityClass，一次 reconcile 可寫進同一 class 的不同值：UpdateWorkloadPriority → PrepareWorkloadPriority → ExtractPriority 每次都自己 Get 一遍，N 個 Workload 就 N 次讀取、彼此不共享結果。LeaderWorkerSet 最尖銳：parallelize.Until 把更新 fan-out 成 N 個 goroutine 併發各自 resolve，class 值若在 fan-out 途中變動，各 component 就被寫成同一 class 的不同值；一般路徑是同形狀的 sequential 版（#13780 的 scale-up 又多一處：quota-reserved slice 與待替換 replica 在同一 reconcile 一起更新）。且不會自癒：WorkloadPriorityClassReconciler 靠 class 名稱 list，發散後雖仍同名、卻得等下一次該 class 值更新才被一起拉回 · 承 #13778/#13780 同一子系統的更深一層；自修 → PR #13904（改為每次 reconcile 只解析一次 LWS 優先權、+763/-54、kind/bug·release-note）審查中（Closes #13820）；另 #13866：WPC 值變更趕在任何 Workload reference 該 class 之前被 reconcile → 該次無事可做、更新被吃掉；Workload 事後帶自查的舊值進來、controller 不 watch Workload，兩者再也對不上、停在過時 priority · 自修 → PR #13920（加上對 Workload 的 watch：開始 reference 某 class 的 Workload 入列該 class、由既有 reconcile 修值；整體比對 reference、僅在 reference 變動時入列以避開自身寫入，用 event handler 而非 map function 以免把離開的 class 也入列、+1000/-0、7 檔、kind/bug·release-note）WIP
open-telemetry/opentelemetry-cpp — Issue #4339 Issue（Bug）· OTLP ForceFlush 可能在請求仍在途時回報成功、且等的是 exporter timeout 而非 caller 剩餘時間：OtlpGrpcClient::ForceFlush 的 wait loop 對「任一通知」就 break（wait_for != timeout 在被喚醒時為真），而 loop 條件才是唯一讀 finished_request_counter 的地方、被這個 break 跳過 → 多個在途請求只要一個完成就結束等待、還回傳剩餘時長而非 predicate；兩個 client 又都以 exporter 的 export_timeout 為界、不理會 caller 傳入的截止時間（overrun）· 自修 → PR #4357 已合併（maintainer owent 已確認反向比較；改以 loop 條件決定、wait 以 caller 剩餘時間為界；屬部分修正、尚未 close #4339，見 Ledger）
open-telemetry/opentelemetry-cpp — Issue #4360 Issue（Bug · triage/accepted）· 生產用 curl HTTP client 會「回報失敗卻仍把請求送出」、並對一次操作送出兩個 terminal event（ext/src/http/client/curl/，每個 HTTP exporter 都跑這支）：三處契約違反：(1) gzip 失敗時 OnEvent(CreateFailed) 後沒 return，直接落到 SendAsync、把可能只壓一半、沒 Content-Encoding 標頭的 buffer 送出去；(2) Cancelled 與 OnResponse 可同時觸發、export 結算兩次；(3) 一次 setup 失敗同時派 ConnectFailed 與 CreateFailed、數 terminal state 的 handler 數到兩次。提案立契約：每次 SendRequest 恰一個 terminal event、送出一個後不再有 bytes 上線 · 自修 → PR #4363（+105/-6）merged（Marc Alff 合併，先收斂 cancelled/response-after 的重複結算；#4360 仍 open、其餘兩處 gzip fall-through 與雙 setup event 待修）· #4363 本身已合併（見 Ledger）
ocudu/ocudu — Issue #726（GitLab） Issue（Bug · 安全/DoS · Open Fronthaul）· OFH U-plane 解碼器遇到不支援的壓縮型別時整個 gNB process 退出：dynamic U-plane decoder 對使用未支援 compression type 的 section 直接 crash → 一個來自 fronthaul 的畸形上行封包就能讓整個 gNB 停擺（crafted packet 即可觸發，dev branch commit b81cbcec2f 重現）· 自行修復 → MR !1296（對不支援的壓縮型別直接丟棄該 U-plane 訊息、不再 crash，審查中，Closes #726）
apache/airflow — Issue #71748 Issue（Bug · Airflow cncf-kubernetes provider）· KubernetesPodOperator 過了 durable reattach 的 uid 檢查後，仍只靠 pod name/namespace 運作：uid 只在從 task state store 讀回 identity 時檢查一次（關掉 reattach 情境），但之後 operator 仍以 name+namespace 操作 → 原 pod 消失、同名新 pod 頂上時，後續操作打到錯的 pod（承 #71743、關聯 #71744）· apache/airflow 屬 Apache（ASF）· 回報中、待修
kubernetes/kubernetes — Issue #141212 Issue（Bug · sig/scheduling · wg/device-management）· per-device nodeSelector 有多個 term 時通過驗證、卻中止整個排程週期：Device.NodeSelector 契約要求「恰一個 term」，slice-level 的 ResourceSliceSpec.NodeSelector 在 validation 有強制、device-level 卻沒有 → 畸形的多-term device selector 通過 API validation；structured allocation 選到該裝置時 allocator 以 hard error 拒絕，但該錯誤沒被 ErrFailedAllocationOnNode 包裝，DynamicResources Filter plugin 因而回傳 framework Error（而非只拒當前節點）→ 取消其餘節點搜尋、中止當前排程週期，且畸形 ResourceSlice 未修正前每次 retry 都重現 · 回報中、待修
kubernetes-sigs/scheduler-library — 可變快照一致性稽核（#6/#7/#8/#9/#12） Issue（Bug 群 · scheduler/snapshot）· 可變 ClusterSnapshot 的 add/remove/rollback/Unpreempt 污染共享快照，undo error 被吞卻回報成功：RestoreState 吞掉 undo error 又照樣還原（#12）、rollback/Unpreempt 回報成功卻沒真的還原（#7）、add/remove 遺留 snapshot-wide affinity（#8）、stale ClusterSnapshot wrapper 可寫進共享 store（#9）、採用上游 framework constructor 會改變語意（#6）· 回報中、待修
koordinator-sh/koordinator — reservation controller 稽核（#3145/#3148/#3149/#3151/#3152/#3154/#3157/#3158） Issue（Bug 群 · scheduler/reservation）· koordinator reservation 一整叢生命週期與一致性缺陷：terminating 或已被取代的 Reservation 仍可被排程並 bound 到 Available（#3154）；同名 replacement 認到 stale UID-qualified workqueue key（#3157）、並把舊 reserve pod 孤兒留在排程佇列（#3152）；reserve pod cycle 不帶 revision、stale node decision 被存到當前 identity 下（#3158）；controller 在其 pod index 反映觸發事件前就先動作（#3151）；reservation plugin cache 更新與依賴它的 wake-up 之間無 happens-before（#3148）；resync 無法停用或停止（#3149）；Reservation plugin 漏註冊其餘 QueueingHint event source（#3145）· 回報中、待修
zephyrproject-rtos/zephyr — i2s/mipi_dbi/dma 驅動稽核（#113310/#113333/#114739/#114741/#115250/#115251/#115499/#115502/#115503/#115504/#115505） Issue（Bug 群 · drivers）· Zephyr 驅動一叢資源生命週期與設定缺陷：esp32 i2s 每次 DROP 洩漏 mem-slab block、之後 i2s_buf_write() 永久 hang（#113310）；i2s_buf_write() 文件寫 -EAGAIN/-ENOMEM 卻以 K_FOREVER 配置、TX slab 耗盡就靜默且不可 kill 地 hang（#113333）；esp32 I2S_DIR_BOTH 的 fatal error 留另一方向仍在跑、PREPARE 回 READY 卻沒停（#115499）；mipi_dbi MIPI_DBI_SPI_CONFIG_DT() 以 controller-wide 檢查設 cs_is_gpio、卻 per-device 索引 GPIO（#115251）；dcnano_lcdif Type A (6800) 模式永遠比不到 format_map（#114739）；mipi_dbi api 測試被 node label typo 到處濾掉（#114741）；compliance 沒檢查 public header 的 designated initializer 是否照 C++ 宣告順序（#115250）；esp32 DMA 的 descriptor 耗盡檢查解參考超出陣列尾端一格、dma_esp32_reload() 還寫進那一格（#115502）、dma_esp32_stop() 在 M2M 區塊後 fall through、同一方向被停兩次（#115503）；esp32 i2s TX start 失敗弄丟已取出佇列的 mem-slab block（#115504）、deferred TX timer 從不取消、DROP 後或下一段串流才觸發（#115505）· #115502/#115503/#115504/#115505 已自行修復並合併（#115507/#115523/#115725、見上方 B 組），其餘回報中、待修
kubernetes/kubernetes — DRA allocator 稽核額外七則（#140424/#140468/#140799/#141103/#141117/#141214/#141216） Issue（Bug 群 · sig/node · wg/device-management）· Kubernetes 核心 DRA allocator 更深一批正確性缺陷（延續已合併的 5 支 v1.37 修正）：device request count 未定上界/溢位安全契約（#140424，pohly 指出它與 #141323 重疊，#141307 與四支 backport 落地後我於 2026-09-12 依約自行關閉）；算 node-allocatable demand 前未拒負的 ConsumedCapacity（#140468）；allowMultipleAllocations 關閉後仍保留 create validation 會拒的 capacity requestPolicy（#140799）；ExtendedResourceCache 供 stale 對應、跨 DeviceClass 更新與碰撞會丟掉 winner（#141103，已由 anshulchikhale30-p 以 #141110 修復並於 2026-08-27 合併關閉，屬社群修復）；GatherPools 完整性在 ResourceSliceCount 不一致時順序相依（#141117；自提的檢查 #141118 經 pohly 與 mortent 兩輪權衡後以「driver 有責任發布正確資料」不收，9/18 改以「not checked」註解合併，2026-09-28 依這個結論自行以 not planned 關閉，同批的 #140806 也一併關掉）；malformed ResourceSlice nodeSelector term 數應 per-node fail-closed（#141214，承 #141212）；device 的 consumesCounters 可為負、validateDeviceCounter 不做 sign check，allocator 以 Sub 從 counter set 扣除時負值反而墊高 available → over-commit 共用 counter set（sibling 的 consumable-capacity 路徑早有 errNegativeCapacity 守衛、counter 路徑漏了，#141216）· 回報中、待修
ocudu/ocudu — #689/#690（GitLab） Issue（Bug）· OCUDU du_high remote-command 的驗證與實際 encode/apply 對不上（同一 du_high_remote_commands.cpp，非 #ntn-audit 的 SIB19 路徑）：#689 SIB3/SIB4 的 neighbour/carrier 清單，parser 不檢查長度、但 RRC ASN.1 encoder 有界（sib3 intra-freq 1..16、sib4 inter-freq 1..8）→ 超長清單通過驗證、被寫進 live SIB 內容並 bump systemInfoValueTag，直到 pack 才失敗、且失敗走 ocudu_assert（Release build 編掉）→ Release 下等於把壞的 SI state 提交了；#690 rrm_policy_ratio_set 驗證並存了 dedicated_ratio，但 du_cell_manager 的 applier 只用強制 ded_rbs=0 的雙參數建構子、且只在有 minimum_ratio/maximum_ratio 時才處理 → dedicated-only 或 no-op 請求被接受卻靜默不套用 · #689 已由維護者 Mateusz Michalski 以 !1259 修復並關閉（2026-08-13），本人回報、維護者修復，屬社群修復；#690 仍回報中
Apache YuniKorn — YUNIKORN-3329（Apache JIRA） Issue · gang scheduling 的 task-group placeholder 需求可從未經驗證的 annotation 溢位成負值：minMember 與 minResource 兩個運算元都直接取自 yunikorn.apache.org/task-groups pod annotation 且未設上界，因此乘積、跨 task group 的加總、乃至 Quantity 的 int64 accessor 本身都可能 wrap，最終把負的 PlaceholderAsk 送進 core（Bug · Major · shim - kubernetes）· 由 YuniKorn PMC 成員 Wilfred Spiegelenburg 分類並指派給我 · 修復 PR #1053 仍在審查中（尚未合併）
OpenAirInterface 5G — Issue #1035 Issue · EURECOM GitLab · 5G 核心開源實作的 bug report

D · 他人回報、由我修復並合併（65 則）

這些 issue 不是我開的。回報的人遇到問題，修正由我送出並合併，GitHub 以 closing reference 綁定，issue 隨 PR 合併而關閉。與上方 B 的差別只在誰先發現：65 則散在 37 個 repo，來自 47 個回報帳號（其中一個是 coderabbit 機器人），不少是該專案的維護者。

OpenTelemetry 家族 · 14 則：opentelemetry-cpp 八則，維護者 dbarker 佔六則（#4265 ElegantQuitQuick flaky 測試、#4369 TSAN 在取消路徑抓到的競態、#4126 LogRecord limits 的實作，以及 #4198、#3979、#3980 三則 clang-tidy），另有維護者 marcalff 的 #3916（file configuration 的 resource detectors）與 pixerit 的 #4062（delta temporality 用 MeterProvider 的起算時間而不是每個 instrument 自己的）；opentelemetry-android #1823（bencehornak，disk buffering 的 exportPeriod 要可設定）、opentelemetry-collector #14114（維護者 mx-psi，metadata.yaml 的 display name）、collector-contrib #50286（jmacd，native histogram 的 span offset 未檢查、由攻擊者控制）與 #42838（gquintana，postgresqlreceiver README 的設定範例無效）、helm-charts #2248（維護者 TylerHelmuth，chart 要跟上 operator 的可用版本），另有 opentelemetry-cpp #4614（維護者 marcalff 2026-09-20 貼出 TSAN 在 OtlpHttpExporterRetryIntegrationTests 抓到的競態並問是不是已知的那條，我認出是新的一條並以 #4618 修掉，2026-09-26 合併）
llm-d-router · 6 則：維護者 liu-cong 的 DumpState 系列，逐個 plugin 實作可觀測的狀態傾印：file-discovery（#1776）、no-hit-lru-scorer（#1790）、mm-embeddings-cache-producer（#1789）、approx-prefix-cache-producer（#1801）、program-aware-fairness（#1798）、precise-prefix-cache-producer（#1794）
jaeger-ui · 5 則：維護者 jkowall 開的 plexus 繪圖層 functional component 遷移 — MeasurableNode（#3389）、NodesLayer（#3394）、SvgLayer（#3399）、SvgLayersGroup（#3400）、SvgEdgesLayer（#3398）
Porch 與 Nephio catalog · 5 則：mozesl-nokia 的 #765（#375 之後的收尾）與 #780（DB cache 處理不了二進位檔）、liamfallon 的 #870（porchctl 指定 namespace flag 時不回報錯誤）與 kushnaidu 的 #900（rpkg CLI 命令間的重複程式碼）由同一支 PR 一併關掉；另有 liamfallon 在 nephio 主 repo 開的 nephio#984 要求 catalog 改用 kptdev 版本的 kpt，由 catalog 那邊的修正關掉
Kueue · 4 則：sohankunkerkar 的 #11994（把 DRA reconcile 的錯誤分成暫時性與確定性）、akram 從 2024 年就開著的 #3439（找不到 WorkloadPriorityClass 時要發事件，主線與 backport 兩支 PR）、#14763（reserved pods 名稱驗證在 0.18 與 0.19 要 gate 住），以及 tenzen-y 審 #13601 時請 coderabbit 開的 #16301（KEP 裡 alternative 的路徑少寫一層 spec，firstAvailable 配額設計要把 sohankunkerkar 一起具名，由 #16313 修掉）
其餘 31 則：envoy #45660（marvin-roesch，把 TLS peer 憑證的驗證狀態帶進 CEL context）、cert-manager #9119（維護者 wallrj，issuing controller 對帶 failureTime 的 CertificateRequest nil 解參考 panic）與 #6331（marcingy，CSR 不是用所指的私鑰簽的）、argo-workflows #16575（維護者 Joibel，archiveWorkflow 把 archiveWorkflowAux 叫了兩次）、OpenTofu #4319（denis256，removed.from 值無效時 crash）、kube-vip #844（Alphadelta14，control plane VIP 的 DHCP 取得失敗）與 #1301（維護者 thebsdbox，收到訊號時傾印設定）、OpenChoreo #2764（維護者 isala404，ReleaseBinding 遇到暫時性錯誤時默默跳過 observability release）、external-secrets #6685（stefan-fast，Infisical 的 dataFrom.find.path 被忽略）、kubeflow/pipelines #12015（mginfn，driver 的 label 與 annotation 要能指定）、kubernetes #136027（HirazawaUi，error 級別的 log 用錯 verbosity）、minikube #22466（Enteee，沒有容器時 minikube status 仍以 0 結束）與 #23035（nirs，containerd 的 preload 測試）、KubeStellar #3475（維護者 francostellari，拿掉 controller 多餘的 role rule）、KEDA #6448（sambou90，artemis scaler 的 TLS 支援）、Harbor #22704（HeyAlaia，改 admin 密碼參數後啟動失敗）、Cortex #6897（維護者 friedrichg，測試要在 arm64 上跑）、Perses #3526（galangel，yAxis 支援奈秒與微秒）、score-spec #53（維護者 mathieu-benoit，Pub/Sub 模擬器 provisioner）、DRANET #204（維護者 gauravkghildiyal，網站要放範例）、prow-github-actions #78（wingyplus）與 #81（yuluo-yx，標籤一起使用時報錯）、rawtoaces #273（soswow，Kelvin 與 mired 的往返）、QGIS #44783（jfbourdon 2021 年開的，qgis_process 要有 --profile／--profiles-path）、Zephyr #98657（ck-telecom，mipi-dbi binding 要有色彩格式）、RocketPy #905（維護者 Gui-FernandesBR，CHANGELOG 自動化）、ASWF dna #120（camerontarget14，逐字稿發佈流程）、Meshery #17135、Microcks #550、Keycloak #43818、kubernetes/website #53090 四則是文件與網站

E · 上游 PR 審查 — 審他人的貢獻（93 筆）

kubernetes/kubernetes · 32 筆：DRA kubelet／scheduler、TAS placement、CompositePodGroup 的節點提名、scheduler 計分溢位、LimitRanger ratcheting、Quantity 行為釘測、volume recycler 逾時上限、資源換算的精度與除以零、exec／attach 串流關閉的時序等
kubernetes-sigs/kueue · 10 筆：DRA extended-resource、workload priority、scheduler snapshot
zephyrproject-rtos/zephyr · 21 筆：以 M5Stack Platforms Maintainer 身分審 M5Stack／ESP32 硬體支援與顯示驅動 PR、含 backport；也審 i2s 驅動的修正，例如 oliverhuahua 修自報 #116030 的 #120597
shovel-heroes-org/shovel-heroes · 8 筆：鏟子英雄，花蓮救災的民間協作平台（131 stars、本人為第三大貢獻者），審後端 API、資料模型與部署流程的 PR
其餘 22 筆散落 ROCm/k8s-gpu-dra-driver、RocketPy、cluster-autoscaler、dra-example-driver、dra-driver-nvidia-gpu、kubernetes/autoscaler、volcano、kubevirt、controller-runtime、argo-workflows、intel-resource-drivers 與 opentelemetry-cpp

查看完整 GitHub profile