From: Eric Biggers <ebiggers@kernel.org>
To: Sasha Levin <sashal@kernel.org>
Cc: stable@vger.kernel.org, stable-commits@vger.kernel.org,
Theodore Ts'o <tytso@mit.edu>,
Andreas Dilger <adilger.kernel@dilger.ca>,
linux-ext4@vger.kernel.org
Subject: Re: Patch "ext4: switch to using the crc32c library" has been added to the 6.12-stable tree
Date: Thu, 29 Oct 2026 21:58:30 +0000 [thread overview]
Message-ID: <20261029215830.GA1254086@google.com> (raw)
In-Reply-To: <2026-10-16-1-daily-reply-0016-ext4-crc32c-drop-6-12-6-6@kernel.org>
On Fri, Oct 16, 2026 at 11:00:21PM -0400, Sasha Levin wrote:
> > Nack. Missing prerequisite commits and didn't Cc the mailing list.
>
> Dropped, thanks.
Thanks. Note that the commit message itself described the prerequisite,
and it intentionally did *not* have 'Cc stable'. Also this was patch 16
of a 19-patch series
(https://lore.kernel.org/all/20241202010844.144356-17-ebiggers@kernel.org/),
which is discoverable from the commit itself via the lore link.
A similar example was
https://lore.kernel.org/all/20260616145143.326415700@linuxfoundation.org/.
That had the same characteristics: commit message itself described the
prerequisite, it intentionally did *not* have 'Cc stable', and it was
patch 18 of a 30-patch series. (That one was actually applied to stable
anyway, despite two people pointing out the missing prerequisites.)
And these don't go to their subsystem mailing list, so there's limited
opportunity for people to catch these incorrect backports.
Can you help me understand how these incorrect backports get queued up
in the first place? At least from the outside, it looks like there's
some automated process that pulls in commits needed for another to apply
cleanly, without anyone really looking at them. (Or if LLMs are making
that decision now, then they're seemingly not being asked to evaluate
whether there are other prerequisites.)
Is there a way to opt out of this until the process can be improved?
- Eric
prev parent reply other threads:[~2026-10-29 21:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20261016171336.3983051-1-sashal@kernel.org>
2026-10-16 17:18 ` Patch "ext4: switch to using the crc32c library" has been added to the 6.12-stable tree Eric Biggers
2026-10-17 3:00 ` Sasha Levin
2026-10-29 21:58 ` Eric Biggers [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=20261029215830.GA1254086@google.com \
--to=ebiggers@kernel.org \
--cc=adilger.kernel@dilger.ca \
--cc=linux-ext4@vger.kernel.org \
--cc=sashal@kernel.org \
--cc=stable-commits@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=tytso@mit.edu \
/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.