From: Eric Biggers <ebiggers@kernel.org>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
linux-doc@vger.kernel.org, workflows@vger.kernel.org,
Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
Randy Dunlap <rdunlap@infradead.org>,
linux-kernel@vger.kernel.org,
Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Subject: Re: [PATCH] docs: submitting-patches: Require base tree information
Date: Tue, 27 Oct 2026 19:57:14 +0000 [thread overview]
Message-ID: <20261027195714.GA2508049@google.com> (raw)
In-Reply-To: <8230fb00-b1a4-47f0-b9de-5d0fa42e9465@kernel.org>
On Tue, Oct 27, 2026 at 03:31:36PM +0100, Krzysztof Kozlowski wrote:
> >> Since this step is pointless - it would be linux-next
> >> (assuming in the first place that this is what the author wanted here!)
> >> - it is a waste of time for me and potential resubmit of series, just to
> >> fulfill requirement which brings no benefits. So I have downside and I
> >> see no upside for my case, when you require the base.
> >>
> >> This might be affecting others as well, but now speaking about my
> >> workflow - I have a lot of independent cleanups, which I stack on top of
> >> each other, sometimes series, sometimes not, but stacking is important
> >> so when I run `make W=1` it passes.
> >>
> >> What's more important, I reject the entire reasoning/cause of this
> >> change, which claimed you cannot review and therefore accept such
> >> patches. It's simply not true.
> >
> > That's not my claim.
>
> That's the claim from commit msg. And wording should rather be "which
> claimed one cannot review".
Emailed patches include only 3 lines of context by default. That's
simply not enough for a proper review in most cases. For a proper
review patches usually have to be applied, which often fails especially
if it's an old patch. (Caveat: as usual, the frequency of this varies
by subsystem. So some people encounter them more than others. Just
because you might not experience this much doesn't mean others don't...)
base-commit (and optional prerequisite-patch-id) can prevent that in
most cases. That's the point. And it helps for applying patches for
any other reason, like testing, or resuming work on on old patchset.
It seems like your concern is that people would bureaucratically ignore
patches without base-commit even when they apply cleanly to "something
obvious"? That is not what I intended for this at all. This is all
about getting more patches to include base tree information.
I also don't think your interpretation is consistent with the actual
commit message or diff of this patch. Regardless, I'd also be glad to
clarify the wording. Do you have any specific wording suggestions?
- Eric
next prev parent reply other threads:[~2026-10-27 19:57 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-20 21:22 [PATCH] docs: submitting-patches: Require base tree information Eric Biggers
2026-10-20 22:07 ` Konstantin Ryabitsev
2026-10-21 6:07 ` Randy Dunlap
2026-10-21 6:35 ` Krzysztof Kozlowski
2026-10-21 6:44 ` Eric Biggers
2026-10-21 6:47 ` Krzysztof Kozlowski
2026-10-21 3:17 ` Weijie Yuan
2026-10-21 6:26 ` Krzysztof Kozlowski
2026-10-21 6:39 ` Eric Biggers
2026-10-21 6:41 ` Krzysztof Kozlowski
2026-10-21 6:49 ` Eric Biggers
2026-10-21 11:55 ` Krzysztof Kozlowski
2026-10-21 15:04 ` Konstantin Ryabitsev
2026-10-21 15:49 ` Krzysztof Kozlowski
2026-10-21 16:37 ` Konstantin Ryabitsev
2026-10-21 16:32 ` Laurent Pinchart
2026-10-22 6:57 ` Krzysztof Kozlowski
2026-10-22 7:25 ` Eric Biggers
2026-10-22 8:29 ` Krzysztof Kozlowski
2026-10-22 10:03 ` Laurent Pinchart
2026-10-26 10:40 ` Laurent Pinchart
2026-10-26 10:48 ` Krzysztof Kozlowski
2026-10-26 11:27 ` Mark Brown
2026-10-27 12:29 ` Laurent Pinchart
2026-10-27 14:31 ` Krzysztof Kozlowski
2026-10-27 19:57 ` Eric Biggers [this message]
2026-10-26 14:02 ` Geert Uytterhoeven
2026-10-26 14:53 ` Laurent Pinchart
2026-10-26 15:37 ` Geert Uytterhoeven
2026-10-26 20:19 ` Laurent Pinchart
2026-10-26 20:51 ` Mark Brown
2026-10-27 12:33 ` Laurent Pinchart
2026-10-27 18:57 ` Mark Brown
2026-10-26 20:12 ` Rob Herring
2026-10-27 7:28 ` Krzysztof Kozlowski
2026-10-27 11:55 ` Rob Herring
2026-10-27 8:10 ` Geert Uytterhoeven
2026-10-27 12:23 ` Laurent Pinchart
2026-10-28 1:14 ` Theodore Tso
2026-10-28 11:57 ` Rob Herring
2026-10-21 14:19 ` Jonathan Corbet
2026-10-21 15:59 ` Krzysztof Kozlowski
2026-10-22 10:04 ` Geert Uytterhoeven
2026-10-22 10:13 ` Krzysztof Kozlowski
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=20261027195714.GA2508049@google.com \
--to=ebiggers@kernel.org \
--cc=corbet@lwn.net \
--cc=konstantin@linuxfoundation.org \
--cc=krzk@kernel.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@infradead.org \
--cc=skhan@linuxfoundation.org \
--cc=workflows@vger.kernel.org \
/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.