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

[Krzysztof Kozlowski <krzk@kernel.org>]

On 21/10/2026 16:19, Jonathan Corbet wrote:
> Krzysztof Kozlowski <krzk@kernel.org> writes:
> 
>> For many of my contributions base is obvious and not needed to be
>> explicitly defined. For all the patches I accept, answer is the same -
>> base is either obvious or if not and patch does not apply, then the base
>> does not matter.
>>
>> Requiring it is just bureaucracy without actual benefit.
>>
>> The only benefit would be if maintainer COULD change its base to apply
>> some patch with odd base... but this cannot happen. Maintainer base is
>> fixed - it's the HEAD of his development branch for given category of
>> commits (e.g. DTS branch for SoC maintainers).
> 
> I fairly routinely get docs patches that don't apply to docs-next; when
> I'm in the mood, I'll try to figure what they *do* apply to, then
> cherry-pick them over.  Base information would make that process easier,
> and even automatable.
> 

Some maintainers do that indeed and I propose not to. Every two months I
see one of my or other folks around my area patch which is being changed
in incorrect way between mailing list and Git. Change is done because:

1. Patch did not apply cleanly (a lot of simultaneous work, so base is
obviously old the moment the maintainer applies such patch)

2. Maintainer tried to resolve that by applying to the correct base (so
followed your process) and then did git rebase or cherry pick to his
final development branch.

3. Maintainer is overloaded and has no time to investigate whether
rebase/cherry-pick from above is truly correct, except building the
code, so every two months result of such rebase is wrong.

This is a real issue because it is very difficult to spot - your commit
is applied, but you never verify whether is applied THE SAME way and
maintainer thinks everything was applied cleanly.

If (1) happens and patch does not apply, the solution is to ask the
contributor to rebase.

So sorry, but the proper base rather encourages risky patch
merging/rebasing, instead of pushing the rebase problem to the person
actually knowing the patch and having hardware to validate it.

Best regards,
Krzysztof