The Patch-Trailer Credit Reference: What Each Tag and Gerrit Vote Proves

This is a lookup reference for judging what a systems engineer actually did when their best work lives in mailing-list trailers and Gerrit votes, not on a GitHub profile. It is for engineering managers, technical founders, developer-relations leads, and technical sourcers who have one name or email address and need to read the record as evidence. Each credit gets its own entry covering what it proves about the named person, how it misleads, and what to check. A procedure follows that ends in a one-line verdict.

Why the upstream record has to be the primary source

For most upstream systems engineers, the commit history and review votes are the only complete record of their work, because their public profiles rarely describe it in searchable terms. A headline tells you what someone chose to advertise. A trailer tells you what a maintainer recorded.

The gap is measurable. In Refolk's index of professional profiles, 496 people in the United States have "linux kernel" in their headline, against 107 in Germany, a 4.6x ratio. The 7.2 kernel release alone took 16,418 non-merge commits from 2,652 developers. That is 5.3 times the entire US headline count. Most people who ship kernel code never say so where a keyword search would find them.

Keyword search is also noisy where it does find matches:

In a 25-profile US sample for "linux kernel", the top employers were Google (4), NVIDIA (3), AMD (2), and Intel (2). The German sample showed Bosch, Intel, IBM Deutschland R&D, and IBM at 2 each, plus Linaro, Collabora, and SUSE. The "chromium" query is worse. At least 5 of the top 10 employers in that sample are unrelated companies whose names happen to match: Homium, Chromis Technologies, Chronius Health, The UC Theatre, and eMagin.

So use the profile to get an email address, and use the upstream record as the evidence. Refolk handles the first half. You describe the role in plain English and it searches GitHub, LinkedIn, and the open web, so you are not relying on a headline keyword. The rest of this reference covers the second half: reading the record.

Terms used throughout:

• Trailer: a Tag: Name <email> line at the end of a commit message that records who did what to a patch.
• Gerrit vote: a label score, such as Code-Review +1 or +2, that a reviewer attaches to a change in the Gerrit review tool.
• lore: lore.kernel.org, the public archive of kernel mailing lists. lei is its command-line client and uses the same search syntax.
• Non-author signoff: a Signed-off-by from someone other than the patch author. It records that this person carried the patch toward mainline.

The seven kinds of credit

Every trailer and vote sorts into one of seven kinds of work: authored, co-developed, reviewed, tested, reported, routed, or blamed-by-Fixes. The verdict at the end names which of these the record actually supports.

• Authored: the person's own commits, found by author address. Their own Signed-off-by is part of this.
• Co-developed: Co-developed-by, always paired with that co-author's Signed-off-by.
• Reviewed: Reviewed-by, Acked-by, Gerrit Code-Review +1 and +2 on other people's changes, and untagged review replies on lore.
• Tested: Tested-by.
• Reported: Reported-by for bugs and Suggested-by for ideas.
• Routed: non-author Signed-off-by, plus MAINTAINERS and OWNERS entries.
• Blamed-by-Fixes: later commits whose Fixes tag points at this person's work.

One tag sits outside this scheme. Assisted-by records that the author disclosed using an AI tool. It is not a kind of work, and its absence tells you nothing.

The person a tag names is often not the person who typed it. The flow below shows where each tag lands on a patch and who usually writes it.

Trailer reference: what each tag proves and how it misleads

Only Signed-off-by is formally restricted to the person it names. Any other trailer can be added by the author or the merger on that person's behalf, so treat it as a claim to verify, not a signature. Each entry below covers "proves" (the strongest claim the credit supports), "misleads when" (the common false reading), and "check" (how to confirm it in git or on lore).

Signed-off-by (as author)

• Proves: the person certified the patch under the DCO (Developer Certificate of Origin) and was involved in developing it. Code without a proper signoff cannot be merged into mainline, so every authored commit has one.
• Misleads when: you count it as a separate credit. It only duplicates the authored count.
• Check: count authored commits and ignore self-signoffs. gitdm's -s option does the same thing.

Signed-off-by (not the author)

• Proves: the person was in the patch's delivery path, meaning they applied it or forwarded it toward mainline. This is routing, and it shows that upstream maintainers trust this person to carry other people's code.
• Misleads when: you read it as a measure of how much they review. A subsystem maintainer who reviews a patch and then applies it usually leaves a Signed-off-by, not a Reviewed-by.
• Check: confirm the person is listed in MAINTAINERS for the files they signed off on.

Co-developed-by

• Proves: the person shares authorship. The kernel rules require every Co-developed-by to be immediately followed by that co-author's own Signed-off-by, so the credit carries their certification.
• Misleads when: you search only by author address. Co-developed work never appears in git log --author.
• Check: grep commit messages for the person's name and every address you know.

Reviewed-by

• Proves: the reviewer claims to have carried out a technical review of the patch to judge whether it is appropriate and ready for inclusion. It is the strongest review claim the kernel defines.
• Misleads when: the author carried it forward from an earlier version that later changed, or when a low count belongs to a maintainer whose review shows up as Signed-off-by.
• Check: find the reviewer's own reply on lore with f:<email>.

Acked-by

• Proves: the acker at least reviewed the patch and said they accept it. That acceptance does not necessarily cover the entire patch, and cross-subsystem acks often cover only the part that touches the acker's own files.
• Misleads when: you weigh it the same as Reviewed-by, or a merger turned a casual "yep, looks good to me" into an Acked-by.
• Check: compare the patch's diffstat against the acker's MAINTAINERS F: lines.

Tested-by

• Proves: the named person successfully tested the patch in some environment.
• Misleads when: it reflects a QA job rather than engineering depth. One AMD tester, Dan Wheeler, holds between 4.8% and 10.1% of all Tested-by credits per release.
• Check: look at the person's authored count. A high Tested-by count next to near-zero authored work describes a testing role.

Reported-by

• Proves: the person found a bug. The kernel docs say it is for bugs and should not be used to credit feature requests.
• Misleads when: you read it as evidence they can fix things. A report shows the person found the problem, not that they solved it.
• Check: open the original report on lore and see whether it contains analysis or only a symptom.

Suggested-by

• Proves: the person had the idea for the patch.
• Misleads when: you treat it as evidence they built it.
• Check: look on lore for the thread where they made the suggestion. A substantive design message is worth more than a one-line request.

Fixes

• Proves: an earlier commit introduced a bug. When a Fixes tag points at one of the person's commits, it records a defect someone else had to repair. In 7.2 alone, 4,830 commits carried a Fixes tag, so having some aimed at your work is normal.
• Misleads when: you use a raw count as a quality score without adjusting for how much the person wrote and where. Prolific authors in busy code collect more.
• Check: work out the ratio of fixed commits to authored commits and compare it with peers in the same subsystem.

Assisted-by

• Proves: if present, the author disclosed using an AI tool. If absent, nothing.
• Misleads when: you read its absence as "wrote it without help". The tag was recommended, not required. Sasha Levin said "enforcement is deliberately avoided", and in 7.3 through rc7 only 1,884 of 18,533 changesets carried it. LWN's Maintainers Summit report concluded that "Assisted-by provides no useful signal", and a patch removing it has been applied to the documentation tree.
• Check: whether the tag is still in the current submitting-patches rules. The last section explains how.

Gerrit vote and ownership reference

In Gerrit-based projects such as Chromium and ChromiumOS, the evidence is votes and file ownership rather than trailers. A Code-Review +2 means the voter holds approval rights, while in ChromiumOS anyone can give a +1. The rules differ between projects, so read each vote against that project's own policy.

Code-Review +1

• Proves: the person looked at the change and approved of it. In ChromiumOS anyone can give a +1. In Chromium, a change from a committer needs one Code-Review +1, and a change from a non-committer needs two separate +1 approvals.
• Misleads when: you add +1 votes together as if they made an approval. ChromiumOS states plainly that two Code-Review+1 labels do not equal a Code-Review+2.
• Query: label:Code-Review=1,user=jsmith

Code-Review +2

• Proves: in ChromiumOS, the person has +2 access, which is restricted to developers (and partners in specific repos). That is a trust grant comparable to routing in the kernel.
• Misleads when: the person gave the +2 to their own change. ChromiumOS developers with +2 access self-apply it, "inheriting" the vote from an earlier patchset, which inflates the count with votes on their own work.
• Query: label:Code-Review=2,user=jsmith matches changes where jsmith gave a +2. Drop self-votes with the non_uploader qualifier or by excluding owner:jsmith.

The reviewedby: operator

• Proves: the person commented on the change after the owner last updated it.
• Misleads when: you read it as a vote. It matches comments, not approvals.
• Use instead: label:Code-Review=<value>,user=<name>.

MAINTAINERS and OWNERS entries

• Proves: the project named the person as responsible for a set of files. In the kernel, MAINTAINERS lists the covered file patterns on F: lines. In Chromium, OWNERS files do this job, and committers cannot bypass code review or OWNERS approval.
• Misleads when: the entry is old and the person no longer works on that area.
• Check: compare the entry against recent non-author signoffs or +2 votes in those paths.

Chromium committer status

• Proves: three existing committers vouched for the person's security credentials and intentions, and at least one of them is listed in an OWNERS file somewhere in chromium/src. According to a secondary report, this vouching replaced an earlier bar of 10 patches.
• Misleads when: you assume the status still means active work. I could not confirm whether Chromium removes committer status after a period of inactivity. The "Become a Committer" page has a "Maintaining committer status" section; read it before you rely on the status.

Base rates: what a normal kernel count looks like

About half of kernel commits carry a Reviewed-by and about one in ten carries a Tested-by. Finding either tag on a candidate's patches is therefore ordinary; volume and spread are what set people apart. The figures below come from LWN's per-release development statistics.

In 7.2 the rates were about 48% Reviewed-by and about 8% Tested-by, with the same tester at 7.0% (117). Review coverage has risen a long way: in 4.11, only 3,099 of 12,546 changesets had a Reviewed-by. For scale, 6.15 had a Tested-by on 1,411 commits and a Reviewed-by on 7,332.

What this means when you read one person's record:

• Reviewed-by is spread thin. The top reviewer never passed 3.1% of credits. A candidate with 100 or more Reviewed-by credits in one cycle is in a very small group, and 10 is ordinary. For a sense of pace, Simon Horman reviewed just over four networking patches a day in 6.15.
• Routing is concentrated. In 4.11, David S. Miller alone held 12.4% of non-author signoffs. Over 50% of changes pass through maintainers who work for just five companies, and over the extended 6.6 cycle Greg Kroah-Hartman applied nearly ten patches a day. Even a small non-author signoff count is the strongest single trust marker in a record.
• Tested-by tracks role. When one person dominates the tag release after release, the tag is measuring who has a QA assignment. Weigh it only next to authored work.
• Per-person routing shares for recent releases are not established in my sources. Treat the 4.11 figure as a picture of how concentrated routing is, not as a current benchmark.

A non-author Signed-off-by is the credit that says upstream trusted this person to carry other people's code.

Once you know routing is the signal you care about, you can search for it directly rather than for a keyword.

How to pull and classify one engineer's record

Pulling a record takes eight passes, from resolving identities to writing a one-line verdict. I put this order together for hiring use. No single source documents it, and none describes the untagged-review or Fixes passes as part of evaluating a candidate. Time to pull a full record is not established either. It grows with the number of addresses and subsystems involved.

The commands below run from a kernel tree checkout, and the lore and Gerrit lines go into those search boxes. Replace the example address with each address from step 1 and run them once per address.

# 1. Aliases
grep -i "jane@example.org" .mailmap

# 2. Authored, by top-level path, then co-developed
git log --no-merges --author="jane@example.org" --format="" --name-only | cut -d/ -f1,2 | sort | uniq -c | sort -rn | head
git log --no-merges -i --grep="Co-developed-by: .*jane@example.org" --oneline | wc -l

# 3. Trailers on other people's patches (subtract any hits she authored)
for t in Reviewed-by Acked-by Tested-by Reported-by Suggested-by; do
  printf "%s " "$t"
  git log --no-merges -i --grep="$t: .*jane@example.org" --oneline | wc -l
done

# 4. Routing: her signoff on commits someone else authored
git log --no-merges -i --grep="Signed-off-by: .*jane@example.org" --format="%ae" | grep -vi "jane@example.org" | wc -l
grep -n "jane@example.org" MAINTAINERS

# 5. Untagged review (lore.kernel.org search box or lei q)
f:jane@example.org AND s:"Re: [PATCH"

# 6. Blame by Fixes
git log --no-merges --author="jane@example.org" --format="%h" > mine.txt
while read h; do git log --oneline --grep="Fixes: $h"; done < mine.txt | sort -u | wc -l

# 7. Gerrit (project search box)
label:Code-Review=2,user=jsmith -owner:jsmith
label:Code-Review=1,user=jsmith
owner:jsmith

Notes on the sheet:

• lore and lei share one query syntax. f: searches the From header, and diff prefixes such as dfn: (diff file name) let you narrow review replies to a subsystem's files. Check the prefix list on the lore search help page before relying on any other prefix.
• gitdm parses git log output the same way, if you want per-employer tables. Its employer mapping comes from email domains, which is one of the failure modes below.
• A Patchwork-based procedure is not documented in my sources. If the project tracks review in Patchwork, check its own docs for a per-person view.

How credit records go wrong

Credit records fail in both directions. Review hides inside signoffs, testing and self-votes inflate counts, and domain-based employer mapping puts work under the wrong company. Each failure below comes with a check you can run in minutes.

1. Review undercount (a false negative). A maintainer who reviews by applying patches gets a Signed-off-by, not a Reviewed-by, so a low Reviewed-by count looks like little review. Check: add non-author signoffs and lore replies to patches (steps 4 and 5).
2. Tested-by from a QA role. One AMD tester holds up to 10.1% of all Tested-by credits in a release, so a high count can describe a job function rather than engineering depth. Check: is the person's own authored count near zero? If so, classify the record as tested, not authored.
3. Carried-forward or converted tags. Authors add Reviewed-by and Tested-by to later versions for the named person, and mergers sometimes turn an informal "looks good to me" into an Acked-by. Check: find the reviewer's original email on lore. No message from the reviewer means a weaker credit.
4. Partial ack. A cross-subsystem Acked-by can cover a single hunk. Check: compare the patch's diffstat with the acker's MAINTAINERS F: lines and count only the overlap as review.
5. Self +2 in Gerrit. ChromiumOS developers with +2 access self-apply CR+2 by inheriting it from an earlier patchset, which inflates their +2 count with their own changes. Check: add non_uploader or exclude owner:X.
6. reviewedby: confusion. The Gerrit reviewedby: operator matches people who commented, not people who approved. Check: use label:Code-Review=<value>,user=X instead.
7. Employer by domain. gitdm assigns employers by email domain, and one secondary source puts the (Unknown) bucket at 16.7% of commits in 7.2. A gmail author can be fully employed and paid to do the work. Check: look at who signed off after them (a corporate maintainer in the chain is a strong hint) and at their profile.
8. Assisted-by absence. About 10% of changesets carried the tag, while the real rate of AI use was described as "surely much higher". Check: none. Absence proves nothing, so leave it out of the verdict.
9. Split identities. Someone who changed employers has commits under several addresses, and missing one undercounts everything. How much .mailmap alias folding changes the counts has not been publicly measured. Check: run every query against every address from step 1 and compare the totals.
10. Headline-keyword noise. A "chromium" headline search returns companies such as Homium and Chromis Technologies. Check: confirm every sourced name against an upstream address before you pull a record.

The size of bot-generated Tested-by credit is not established publicly either. If a Tested-by address looks automated, read its lore history before you count it.

Writing the one-line verdict

The verdict is one sentence that names the primary kind of work the record supports, the subsystem, the counts behind it, and what you discounted. If the record cannot support a claim, the verdict says so rather than guessing.

Two axes do most of the sorting: how much the person wrote in the area, and whether upstream trusts them to route or approve other people's code.

<Name> (<addresses checked>): record supports <authored | co-developed | reviewed | tested | reported | routed> work in <subsystem or paths>.
Evidence: <n> authored, <n> co-developed, <n> non-author signoffs, <n> Reviewed-by (<n> confirmed on lore), <n> Acked-by, <n> Tested-by, <n> lore review replies, Gerrit +2 <n> (self-votes removed), Fixes ratio <fixed>/<authored>.
Discounted: <carried-forward tags | partial acks | QA-shaped Tested-by | self +2 | domain-based employer guess>.
Not established: <what this record cannot show, e.g. work on private trees, current activity in an old MAINTAINERS entry>.

Patterns to watch for when you write it:

• Routed and reviewed, little authored: say so plainly. This person keeps other people's code correct, and that is a different job from writing new drivers.
• High Tested-by, near-zero authored: "record supports testing, not authorship." Do not upgrade it.
• Authored with a high Fixes ratio compared with subsystem peers: note it as a question for the interview, not a verdict. Busy code collects Fixes tags.
• Thin record: "not established from the upstream record." Much systems work happens in private trees, and a thin public record does not prove the person did little.

Keeping this reference current

Base rates and tag rules change from release to release, so check four things before relying on the numbers here: the latest release statistics, the current submitting-patches rules, the project's committer policy, and your Gerrit version's search operators. None of these needs more than a page read.

• Release base rates. LWN publishes development statistics for each release, written by Jonathan Corbet. Add a row to each base-rate table from the newest article and check that the top reviewer is still under the 3.1% ceiling. If that ceiling moves, change what you call "a lot" of Reviewed-by credit.
• Assisted-by status. The tag arrived with the coding-assistants document in 7.0. Sasha Levin's removal patch, which deletes the Assisted-by: LLM [TOOL1] [TOOL2] format and the matching checkpatch logic, was applied to the documentation tree but had not reached mainline when last reported. Check Documentation/process/ in the current tree.
• Trailer definitions. Re-read the kernel's submitting-patches document when a candidate's record contains a tag not covered here. Its definitions are the authority, and this reference only interprets them.
• Chromium committer rules. Read the "Maintaining committer status" section of the Become a Committer page before treating committer status as proof of current activity.
• Gerrit operators. Search operators vary between Gerrit versions. Confirm that non_uploader and label:...,user= behave as described in your project's Gerrit search documentation.

For a long-running search, pull each finalist's record again at the start of every release cycle, because routing and ownership change faster than profiles do. When you need more candidates like the strongest one, describe that record to Refolk in plain English (the subsystem, the routing role, the region) and run this procedure on each person it returns.