From: Fuad Tabba <fuad.tabba@linux.dev>
To: Chris Mason <mason@kernel.org>
Cc: sashiko@lists.linux.dev,
Roman Gushchin <roman.gushchin@linux.dev>,
ihor.solodrai@linux.dev, ast@kernel.org, kuba@kernel.org,
Fuad Tabba <tabba@google.com>
Subject: Re: [RFC] reworking the review-prompts subsystem guide
Date: Sat, 10 Oct 2026 16:53:21 +0100 [thread overview]
Message-ID: <20261010155321.2539213-1-fuad.tabba@linux.dev> (raw)
In-Reply-To: <c007a163-91a6-4e2a-b8de-057b61d369aa@app.fastmail.com>
Hi Chris,
On Fri, 09 Oct 2026 18:57:53 +0100, "Chris Mason" <mason@kernel.org> wrote:
[...]
> There's already a way to pass specific parts verbatim, which feels more
> correct than under a "new code" label. We can play around with a few
> ideas though.
A verbatim file works. I'll send a KVM/arm64 one, policy only, with the
patch that brings back the dropped questions.
[...]
> I'll do another run and put the full build up. We can see if it's too big
> to be useful or if we can make the index strong enough to get around
> needing the per-model analysis.
When it's up I can put numbers on it: I have a test set of 115 buggy
KVM/arm64 commits, fixed since January, each paired with what fixed it,
plus the Sashiko findings on KVM/arm64 patches since July that a human
answered. The hand guides are running on the bugs now; the current build
and the full one are next.
[...]
> Absolutely. The index is pretty dumb, we can do a lot better.
Most index lines already name the source file of their answer, so one
cheap step is to search for the files the patch touches as well as its
symbols. A directory table is still the place for the rest: the
placement rule for a new hypercall was answered from
arch/arm64/kvm/pkvm.c, which such a patch doesn't have to touch.
[...]
> A related question is how often do I need to rebuild in order for
> the guides to be useful? I'd assume the absolute minimum is every
> final release, but every RC is also reasonable.
I think every rc is enough for mainline. What it can't reach is a fix
that lands between rcs, or a review against -next, and the source file
on the index line could catch part of that: re-check an answer whose
file changed since the build's commit before relying on it.
[...]
> The build script can rebuild a single guide, or people can just have
> their agents hand edit the build? It's a good point, we should have
> AGENTS.md record some best practices.
A hand edit to the guide fails check-built-guide.py, and a rebuild from
the unchanged question can bring the wrong answer back. For AGENTS.md,
how about: edit the answer file (an exception to the never-edit-build
rule, but the check still passes), re-render and re-index with no model,
and sharpen the question in the same change so the fix isn't only in
the output.
Cheers,
/fuad
prev parent reply other threads:[~2026-10-10 15:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-02 19:04 [RFC] reworking the review-prompts subsystem guide Chris Mason
2026-10-02 21:18 ` Chuck Lever
2026-10-04 9:17 ` Chris Mason
2026-10-05 19:58 ` Jakub Kicinski
2026-10-05 21:14 ` Roman Gushchin
2026-10-05 21:53 ` Jakub Kicinski
2026-10-05 23:37 ` Ihor Solodrai
2026-10-06 21:22 ` Ihor Solodrai
2026-10-07 9:00 ` Chris Mason
2026-10-09 14:17 ` Fuad Tabba
2026-10-09 17:57 ` Chris Mason
2026-10-10 15:53 ` Fuad Tabba [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261010155321.2539213-1-fuad.tabba@linux.dev \
--to=fuad.tabba@linux.dev \
--cc=ast@kernel.org \
--cc=ihor.solodrai@linux.dev \
--cc=kuba@kernel.org \
--cc=mason@kernel.org \
--cc=roman.gushchin@linux.dev \
--cc=sashiko@lists.linux.dev \
--cc=tabba@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.