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

[Geert Uytterhoeven]

Hi Krzysztof,

On Wed, 21 Oct 2026 at 18:01, Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
> On 21/10/2026 16:19, Jonathan Corbet wrote:
> > Krzysztof Kozlowski <krzk@xxxxxxxxxx> 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.

This happens a lot in DTS-enablement patches: multiple people are
working on different devices for the same SoC/board, so half of their
patches insert new device nodes at the same conflicting location.
Perhaps we can teach to git how to handle DTS addition conflicts?

So your solution is that I apply one new patch every day and publish
the result, and ask all other N-1 series to be rebased? Obviously this
not only applies to queuing patches, but also to applying patches for
build/run testing during review?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds