mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®