Re: [PATCH] docs: submitting-patches: Require base tree information

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

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.

> 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.

> 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.

> So please come with proper reasoning and then maybe even it would be
> fine to require the tag. But if reasoning is not correct, changing
> policy is not right.

-- 
Regards,

Laurent Pinchart