From: Krzysztof Kozlowski <krzk@kernel.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Eric Biggers <ebiggers@kernel.org>,
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: Thu, 22 Oct 2026 08:57:55 +0200 [thread overview]
Message-ID: <73d01869-b536-4fcd-a139-6f9d0a043347@kernel.org> (raw)
In-Reply-To: <20261021163242.GB325924@killaraus.ideasonboard.com>
On 21/10/2026 18:32, Laurent Pinchart wrote:
> On Wed, Oct 21, 2026 at 01:55:37PM +0200, Krzysztof Kozlowski wrote:
>>
>>> there's no base-commit? Including any historical patch (from
>>> months/years ago), patches with dependencies, etc.
>>
>> Dependency is something else, but for every other patch:
>> 1. For testing/CI: you apply on top of next
>> 2. Every other case the maintainer knows where to apply it, because it
>> is his HEAD of next-branch.
>>
>> I am repeating myself, but I really had no single problem of lack of
>> knowledge where to apply a patch as a maintainer or reviewer of some
>> subsystem, thus maybe I do not understand the actual problem you are
>> experiencing.
>
> When I review patches, I often need to apply them to a tree, mainly to
> see the context, but sometimes also to test them. I have encountered
> many cases where the patch wouldn't apply on the current for-next branch
> of the relevant subsystem. That's often because the patch had
> dependencies. When I'm lucky they are listed manually in the cover
> letter with a link to a branch, but that's far from being the common
> case. I then have to ask the submitter to provide a branch, or enough
> information to recreate a branch. Having base information (base-commit,
> prerequisite-patch-id, and possibly base-tree) would save me quite some
> time.
>
> I understand your concern about maintainers cherry-picking and sometimes
> introducing issues as a result. In that case I also prefer asking the
> submitter to rebase, retest, and resubmit. That's not what I want to use
> base information for, in my case it helps with the review process.
That's valid and for 95% (guessing the number...) of cases will be
solved by having linux-next as a base, thus requiring the base
information is redundant. It's just linux-next.
When patchset does NOT apply on linux-next or maintainer tree is
non-obvious, the base should be provided, but that is only "if ->
should". I think the proposal here is a bit different.
Best regards,
Krzysztof
next prev parent reply other threads:[~2026-10-22 6:58 UTC|newest]
Thread overview: 24+ 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 [this message]
2026-10-22 7:25 ` Eric Biggers
2026-10-22 8:29 ` Krzysztof Kozlowski
2026-10-22 10:03 ` Laurent Pinchart
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=73d01869-b536-4fcd-a139-6f9d0a043347@kernel.org \
--to=krzk@kernel.org \
--cc=corbet@lwn.net \
--cc=ebiggers@kernel.org \
--cc=konstantin@linuxfoundation.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.