From: Mark Brown <broonie@kernel.org>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Jiri Kosina <jikos@kernel.org>,
ksummit@lists.linux.dev, sashiko@lists.linux.dev
Subject: Re: Patch pre-submission to Sashiko
Date: Sun, 18 Oct 2026 12:46:47 +0100 [thread overview]
Message-ID: <atSxp7OhWVTKE7Ny@sirena.org.uk> (raw)
In-Reply-To: <DM7BL6J0WCXU.1I38BKL4RJLFI@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1691 bytes --]
On Sat, Oct 17, 2026 at 06:20:47PM +0000, Alexei Starovoitov wrote:
> On Sat Oct 17, 2026 at 5:28 PM UTC, Jiri Kosina wrote:
> > Neither myself nor anyone else did comment with any review feedback,
> > except for Sashiko. Which I believe is what triggered all the immediate
> > resubmissions.
> > I don't think this is sustanable.
> I think it's just fine. I encourage developers to keep the spam going.
> You can simulate github style squah of v1->v2->v3 in your inbox.
> Ask your agent to monitor inbox, archive vN when vN+1 arrives
> and summarize v1->vN discussion. Then you'll always have the latest
> patch set to look at and a summary of what happened when you were away.
> Then sit on it for a day or a week to see whether respin
> cycle has ended (and bots stopped talking to each other) and then
> do a human part of maintainership.
It's not just LLM users getting caught by this, I've seen people I know
going multiple rounds in what appears to be a very human fashion trying
to shut the warnings up. Given that some maintainers won't look at
anything until all Sashiko is happy it's a totally reasonable thing to
do but I can't imagine it's an inspiring experience. A lot of that has
been with valid but not interesting or useful issues (the stereotypical
example is something like missing return value checks on a MMIO regmap).
Even with people who appear to be LLM users I've seen people going all
weekend with no human review only to find that the first human review is
that the approach is completely wrong and they were wasting their time
fixing the detail issues that were being flagged which I can't imagine
is especially pleasant.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2026-10-18 11:47 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-17 17:28 Patch pre-submission to Sashiko Jiri Kosina
2026-10-17 18:02 ` Theodore Tso
2026-10-19 11:02 ` johannes.goede
2026-10-17 18:20 ` Alexei Starovoitov
2026-10-17 18:38 ` Arnaldo Melo
2026-10-19 7:02 ` Dan Carpenter
2026-10-18 11:46 ` Mark Brown [this message]
2026-10-17 18:20 ` Linus Torvalds
2026-10-17 20:10 ` Roman Gushchin
2026-10-18 13:41 ` Steven Rostedt
2026-10-18 18:41 ` Kees Cook
2026-10-18 18:58 ` Linus Torvalds
2026-10-19 5:55 ` Oliver Slapinski
2026-10-17 19:42 ` Andrew Lunn
2026-10-18 11:54 ` Mark Brown
2026-10-18 16:48 ` Laurent Pinchart
2026-10-19 6:25 ` Krzysztof Kozlowski
2026-10-19 7:26 ` David Woodhouse
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=atSxp7OhWVTKE7Ny@sirena.org.uk \
--to=broonie@kernel.org \
--cc=alexei.starovoitov@gmail.com \
--cc=jikos@kernel.org \
--cc=ksummit@lists.linux.dev \
--cc=sashiko@lists.linux.dev \
/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.