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: Tue, 27 Oct 2026 15:31:36 +0100 [thread overview]
Message-ID: <8230fb00-b1a4-47f0-b9de-5d0fa42e9465@kernel.org> (raw)
In-Reply-To: <20261027122952.GB2133989@killaraus.ideasonboard.com>
On 27/10/2026 13:29, Laurent Pinchart wrote:
> On Mon, Oct 26, 2026 at 11:48:16AM +0100, Krzysztof Kozlowski wrote:
>> On 26/10/2026 11:40, Laurent Pinchart wrote:
>>> On Thu, Oct 22, 2026 at 08:57:55AM +0200, Krzysztof Kozlowski wrote:
>>>> 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.
>>>
>>> What's the downside though ? As git can easily provide the base
>>> information once configured to do so, what's the downside of asking
>>> contributors to include it ?
>>
>> For me the downside is that if you require it, half or more of my
>> patches would be rejected
>
> I don't think we want to automate rejection of patches that provide no
> base information, and certainly not as a first step. The goal as I see
> it is to encourage people to provide the information. It's a process
> that will take time.
We already encourage that in current wording and b4 automatically
provides that.
If you want to encourage, do not make it a requirement "with only rare
exceptions".
>
>> and I would need to add unnecessary step to
>> remember.
>
> It doesn't have to require manual work every time you send paches.
> format.useAutoBase in conjunction with specifying upstreams of branches
> helps.
But then base would point nowhere... Upstream of my branches are my
github branches, so I always know what is up2date against my github.
Otherwise how do you track - with multi-machine and fully backed up
repos - whether your local changes are updated against your backed up
branch on github/forge?
>
>> 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".
Best regards,
Krzysztof
next prev parent reply other threads:[~2026-10-27 14:31 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-20 21:22 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 [this message]
2026-10-27 19:57 ` Eric Biggers
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=8230fb00-b1a4-47f0-b9de-5d0fa42e9465@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®