Turning Upstream Feedback into Trackable Work Items

Good to continue from the restored V1 baseline. You now have a fixed patch series, an exact kernel base, and recorded validation results. The next asset is equally important: a review record that lets you answer a maintainer's question without losing what they actually asked, where they asked it, or which revision they reviewed.

This lesson builds a feedback work list, not a list of assumed fixes. Each upstream observation will retain its original email evidence and surrounding patch context. Separately, it will have one or more small tasks with explicit completion proof. That separation is what makes the later AI loop reviewable rather than merely productive.

By the end, you should be able to take a V1 mailing-list thread and produce a work list in which every substantive comment or question is traceable, actionable, and still faithful to the original review discussion.

---

Keep two layers: evidence and work

A review comment has two different jobs:

1. It is historical evidence: a particular person wrote particular words, in response to a particular patch revision and often a particular hunk.
2. It is engineering input: you must determine what needs to change, what proof is required, or what question needs a human answer.

Do not combine those jobs in one vague note such as:

"Reviewer says reset handling is wrong; fix reset."

That note destroys important distinctions:

• Did the reviewer say it was wrong, ask how it works, or suggest a different API?
• Was the comment attached to V1 patch 2, the cover letter, or a later V2 reply?
• Did it refer to a specific changed line?
• Is the proposed fix a DSA integration change, a Device Tree question, or a hardware behavior assumption?
• What would demonstrate that the concern is actually addressed?

Instead, use two linked records:

Record	Purpose	May it be edited?
Feedback record	Preserves the mailing-list evidence and neutral interpretation	Treat source fields as immutable
Task record	States the work to do, its limits, and the proof needed to close it	Yes, with a change history

The feedback record answers, “What happened in review?” The task answers, “What must we establish or change?”

A single email may contain several independent concerns. Split it into separate feedback records when the reviewer changes topic, but keep every record linked to the same source message. Conversely, one concern can produce multiple tasks. A request to change a property name may require a binding update, driver update, DT example update, and schema validation evidence.

The rule is:

Preserve comments at the granularity at which they were made; plan work at the granularity at which it can be completed and checked.

This is particularly useful for driver work. A reviewer may correctly notice an unsafe register access but incorrectly guess why it is unsafe. Preserve both the observation and the wording. Do not let an AI agent turn the suggestion into a hardware fact without manual evidence.

---

Capture the complete review thread before interpreting it

Your V1 mailbox is already an immutable submission artifact. The review corpus needs comparable care. It should include the V1 cover letter, every patch, direct replies, replies to replies, automated reports, and follow-up messages that materially discuss the series.

B4's review tracking facilities can help discover revisions and display the full thread. Its interface is useful for navigation, but your project should also retain its own exported evidence: message identifiers, raw messages or mailbox files, collection time, and checksums.

What to preserve for each source message

Create a dedicated review-artifact area beside the baseline artifacts:

driver-project/
├── artifacts/
│   ├── v1-mail/
│   ├── review-mail/
│   │   ├── raw/
│   │   ├── thread-index.yaml
│   │   └── SHA256SUMS
│   └── manifests/
├── review/
│   ├── feedback.yaml
│   ├── tasks.yaml
│   └── intake-log.md
└── ...

For each email in the thread, record at least:

Field	Why it matters
message_id	Stable identity for a patch or reply
in_reply_to and references	Preserves the thread relationship
from, date, and subject	Identifies the reviewer and review moment
source_series_version	Distinguishes comments on V1 from comments on later revisions
target_patch_message_id	Identifies the exact patch being discussed, if applicable
patch_position	Captures a subject such as 2/4 without treating it as a permanent patch identity
raw_path and sha256	Lets you verify the preserved source later
collection_utc	States when the corpus was collected

A comment may reply to the cover letter, a specific patch, or another review email. Do not force every message into a patch number. Use an explicit context type such as:

• cover-letter
• patch
• inline-patch-comment
• thread-reply
• automated-report
• reviewer-follow-up

If the message is on a later revision, retain that fact exactly. A useful review point made on V2 may inform V1 repair work, but it is not evidence that the reviewer saw or approved V1. Record first; decide relevance later.

Do not let the tool's view replace the source

A review dashboard is an index, not the source of truth. Preserve the raw mail or a complete mailbox export, then generate a compact thread index. For example:

thread:
  series_key: "vendor-switch-v1"
  root_message_id: "<v1-cover-letter-message-id>"
  collected_utc: "2025-03-08T14:20:00Z"
  tool:
    name: "b4"
    version: "<recorded-version>"

messages:
  - message_id: "<review-message-id>"
    in_reply_to: "<patch-2-v1-message-id>"
    references:
      - "<v1-cover-letter-message-id>"
      - "<patch-2-v1-message-id>"
    from: "<reviewer-name and address>"
    date: "<original-date-header>"
    subject: "Re: [PATCH v1 2/4] net: dsa: ..."
    source_series_version: 1
    target_patch_message_id: "<patch-2-v1-message-id>"
    patch_position: "2/4"
    context_type: "inline-patch-comment"
    raw_path: "artifacts/review-mail/raw/<safe-file-name>.eml"
    sha256: "<digest>"

Do not alter the original email body to make it easier to parse. If you clean up a quote for display, retain the raw message and label the cleaned form as derived material.

---

Turn an observation into a checkable task

The core transformation is not paraphrasing. It is adding a precise engineering contract beside the original words.

A useful task statement has five parts:

1. Action: what to investigate, change, explain, or ask.
2. Scope: the affected patch, files, functions, binding, or test artifact.
3. Constraint: what must not be assumed or changed.
4. Completion criterion: the condition that says the task is complete.
5. Closure proof: the artifact that demonstrates completion.

For example, a weak task might say:

Address the phylink comment.

A checkable task has a form closer to this:

Compare the V1 phylink callback usage in <function> with the target kernel's DSA and phylink call-context requirements. If the callback is invalid, make the smallest lifecycle-safe correction. Completion requires a code reference supporting the chosen rule, the relevant build and static-check logs, and a draft reviewer reply that answers the original concern.

This does not assume the reviewer is right about the implementation. It commits to answering the concern using evidence.

Separate exact wording from neutral interpretation

The work list needs both, but they must never be confused.

feedback:
  - id: "FB-V1-014"
    source:
      message_id: "<review-message-id>"
      source_series_version: 1
      target_patch_message_id: "<patch-2-v1-message-id>"
      patch_position: "2/4"
      context_type: "inline-patch-comment"
      raw_message: "artifacts/review-mail/raw/<safe-file-name>.eml"
      raw_message_sha256: "<digest>"
      locator: "Comment following the quoted hunk containing <distinctive code text>"
      file: "drivers/net/dsa/<driver>.c"
      hunk_context: "<exact nearby diff context or null>"

    original_wording: |-
      <verbatim reviewer comment, including any question marks,
      qualifications, and requested rationale>

    neutral_interpretation: >-
      The reviewer asks for justification of the selected resource or API
      lifetime. The comment does not itself establish hardware behavior.

    tasks:
      - id: "TASK-V1-014-A"
        statement: >-
          Establish whether <resource or API> lifetime in <function> follows
          target-kernel ownership rules, and either make the minimal supported
          change or provide an evidence-backed explanation.
        scope:
          patches:
            - "V1 patch 2/4"
          files:
            - "drivers/net/dsa/<driver>.c"
        constraints:
          - "Do not infer hardware behavior from current V1 code."
          - "Do not change unrelated probe or teardown paths."
        completion_criteria:
          - "The chosen behavior is supported by target-kernel code or documentation."
          - "Any code change has recorded build and static-check results."
          - "A reviewer-response draft directly addresses the original wording."
        required_proof:
          - "Source references recorded in the task evidence field."
          - "Named check logs with exit codes."
          - "Exact patch range reviewed."
        status: "OPEN"

The text under original_wording must be verbatim. Do not “improve” grammar, expand abbreviations, or remove uncertainty words such as “perhaps,” “why,” or “I think.” Those qualifiers can determine whether the correct next step is a code fix, an explanation, or a question back to the reviewer.

The neutral_interpretation is deliberately less forceful. It should identify the engineering concern without claiming a conclusion not present in the email.

When one comment produces more than one task

Suppose a reviewer writes one paragraph asking for:

• a binding property rename;
• a schema constraint;
• matching driver property handling;
• an explanation of reset timing.

That is one source message, but not one implementable task. Create one feedback record with the exact paragraph, then create separate task records linked to it.

This makes partial progress visible without falsely claiming the whole comment is done. The property rename can proceed through binding and driver validation. The reset timing portion may need manual evidence and remain blocked. Do not hold the safe Device Tree work hostage to a hardware-manual ambiguity, and do not “solve” the timing issue by copying behavior from another switch driver.

---

Define proof before any agent edits code

A task is checkable when another engineer can inspect its evidence and independently decide whether its completion criteria were met. A successful compile is sometimes part of that proof, but it is not proof of every kind of review concern.

Use proof types that match the task.

Concern type	Suitable closure proof	Insufficient proof
Build or warning issue	Named build log, exit code, relevant configuration, and diff	“It builds on my machine”
DSA API or lifecycle concern	Target-kernel API or call-path evidence, code diff, build/static logs	A similar-looking driver alone
Device Tree binding concern	Binding diff, example review, dt_binding_check, and relevant dtbs_check logs	YAML syntax validity alone
Style or maintainability request	Focused diff and reviewer response explaining the change	A broad unrelated cleanup
Hardware behavior question	Exact hardware-manual evidence, or a focused human answer recorded as such	Current V1 behavior or an analogy to another device
Reviewer asks “why?”	Evidence-backed explanation, plus code or documentation change if needed	A reply that merely restates the code

The last two categories are where agent workflows commonly fail. An agent may find a plausible register sequence in an analogous driver and produce a polished explanation. That is not hardware proof. If the manual is unclear, incomplete, contradictory, or cannot be understood confidently, the correct task outcome is a concise human question, not a guessed code change.

A suitable task statement in that case is:

Locate manual evidence for the reset deassertion order requested in FB-V1-021. If the available manual sections do not establish the order, produce a focused question naming the register, bit, transition, and missing fact. Block hardware-programming changes until the question is answered.

Its proof is either an exact manual reference or a documented human decision. It is not a successful build.

---

Prepare for reviewer replies without writing them yet

Linux kernel review expects comments to be answered, including comments that lead to no code change. Later, your V2 cover letter and replies will need to say what changed and why.

Add two response-oriented fields to every substantive task:

review_response:
  required: true
  response_status: "NOT_DRAFTED"
  response_claim_limit: >-
    Must not claim test coverage, hardware behavior, or reviewer agreement
    that is not backed by task evidence.
  source_feedback_id: "FB-V1-014"

A later response can then be short and specific:

• what changed;
• why that addresses the comment;
• which check or source supports the claim;
• any limitation still requiring a human decision.

For now, do not write the response as if the task were complete. A placeholder such as “Fixed” is worse than no draft because it creates pressure to retrofit evidence after the fact.

---

A disciplined AI-assisted intake pass

AI is useful here as an extractor and organizer, not as an authority on what a reviewer “must have meant.” Give it a narrow, read-only intake job.

A tool-neutral instruction can look like this:

Inputs:
- Immutable V1 mailbox and review-message corpus
- Thread index with message identifiers
- V1 patch list and file paths

For every substantive upstream comment or question:
1. Create a feedback record with exact original wording.
2. Preserve message ID, parent message ID, author, date, subject,
   reviewed series version, target patch identity, and code context.
3. Write a neutral interpretation that distinguishes an observation,
   request, question, and unproven hypothesis.
4. Create one or more small tasks with scope, constraints, completion
   criteria, and required proof.

Rules:
- Never rewrite or merge original reviewer wording.
- Never assign a V2 comment to V1 without recording its actual source version.
- Never infer hardware facts from V1 code, another driver, or unclear manuals.
- Mark missing context as missing; do not invent it.
- Do not edit source files during intake.
- Output a coverage report listing every reviewed message and its disposition.

The human review step is not optional. Inspect a sample of records from each reviewer and each patch, especially inline comments. Check that quoted review text was not confused with the reviewer's own statement and that an AI summary did not silently convert a question into a mandate.

Intake completion checks

Before considering the work list ready for the next lesson, verify these conditions:

• Every message in the captured thread has a disposition:
  • one or more feedback records;
  • RECORD_ONLY for acknowledgements or non-actionable administrative mail;
  • or an explicit explanation of why it contains no review input.
• Every substantive feedback record has:
  • a stable feedback ID;
  • a source message ID;
  • an exact source version;
  • verbatim wording;
  • enough context to find the comment again;
  • at least one linked task.
• Every task has:
  • one narrow statement;
  • boundaries on what it must not assume;
  • completion criteria;
  • required evidence;
  • a link back to its feedback record.
• The raw source messages and their checksums are present.
• No task claims a fix, test result, hardware fact, or reviewer agreement that has not yet been demonstrated.

Keep even apparently repetitive comments as separate records for now. Do not merge them, decide they are obsolete, or choose which one takes priority yet. The next lesson will handle repeated, linked, conflicting, and potentially no-longer-relevant feedback without destroying this source-level traceability.

---

Key takeaways

A good review work list is a small evidence system, not a collection of reminders.

• Preserve raw mail, message IDs, threading, patch revision, and inline context.
• Store the reviewer's exact words separately from your neutral interpretation.
• Convert each substantive concern into a task with scope, constraints, completion criteria, and required proof.
• Split multi-part comments into small tasks, while retaining the shared source record.
• Match proof to the claim: builds do not prove hardware behavior, and analogous drivers do not prove target-device semantics.
• Use AI to extract and structure feedback, but require it to preserve uncertainty and never invent missing context.
• Prepare a response path for each task, without claiming resolution before evidence exists.

Next, you will examine the captured records for duplicates, dependencies, conflicts, and stale comments, then define the evidence required to close each task and connect it to the eventual patch and reviewer reply.