Linux review tags and reverts
Kernel git history: “Reviewed-by” on commits later labeled bug-introducing, a revert that did not stop the same class of change, and -stable tags that do not mean the hunk is identical. Checklists can stay green while the harm continues.
What. We look at Linux history that already exists: review tags on commits, a revert and later re-entry of the same title, and listed -stable tags versus actual patch hunks.
Why. A process can treat “reviewed” or “reverted” as the stop. If those symbols stay green while a later bug or a silent hunk change continues, the check did not have a handle that bites.
Witnesses.
- Grounding viability (C-004a): whether a green
Reviewed-byon a commit still means that commit did not later carry a bug label. - Correction-channel integrity (C-005): whether a revert stopped the same class of change from re-entering.
- Successor stability (C-006): whether listed
-stabletags mean the patch hunk is identical to upstream. - MB10 — Successor Gaming: the checklist-green / unlisted-invariant-fails pattern on real maintainer history.
Host.
Linux kernel history: Zenodo Perceval dump (record 10654193), git.kernel.org patches, and a linux-6.1.y shallow clone.
Setup.
Frozen fixture h2-linux-v1.json, protocol h2-v1.2.0. Checker check_h2.py. Review tags are joined onto developer-labeled bug-introducing commits; one named revert/re-entry and one -stable versus upstream hunk pair are frozen.
Analysis.
Does a Reviewed-by on the same commit as a later-labeled bug-introducing SHA stay green? Did a revert stop the same class of change (same title later re-entering)? Do listed -stable tags mean the patch hunk is identical? Reviewed-by is also refused as a forge-proof safety metric (common on later-labeled bugs; no cost-of-faking bound).
Finding.
Reviewed-by appears on many later-labeled bug-introducing commits; a revert did not stop same-title re-entry; -stable listed tags can hide hunk changes. Full results