Re: [PATCH] docs: submitting-patches: Require base tree information
From: Geert Uytterhoeven
Date: Mon Oct 26 2026 - 10:06:33 EST
Hi Laurent,
On Mon, 26 Oct 2026 at 11:48, Laurent Pinchart
<laurent.pinchart@xxxxxxxxxxxxxxxx> wrote:
> On Thu, Oct 22, 2026 at 08:57:55AM +0200, Krzysztof Kozlowski wrote:
> > On 21/10/2026 18:32, Laurent Pinchart wrote:
> > > On Wed, Oct 21, 2026 at 01:55:37PM +0200, Krzysztof Kozlowski wrote:
> > >>
> > >>> there's no base-commit? Including any historical patch (from
> > >>> months/years ago), patches with dependencies, etc.
> > >>
> > >> Dependency is something else, but for every other patch:
> > >> 1. For testing/CI: you apply on top of next
> > >> 2. Every other case the maintainer knows where to apply it, because it
> > >> is his HEAD of next-branch.
> > >>
> > >> I am repeating myself, but I really had no single problem of lack of
> > >> knowledge where to apply a patch as a maintainer or reviewer of some
> > >> subsystem, thus maybe I do not understand the actual problem you are
> > >> experiencing.
> > >
> > > When I review patches, I often need to apply them to a tree, mainly to
> > > see the context, but sometimes also to test them. I have encountered
> > > many cases where the patch wouldn't apply on the current for-next branch
> > > of the relevant subsystem. That's often because the patch had
> > > dependencies. When I'm lucky they are listed manually in the cover
> > > letter with a link to a branch, but that's far from being the common
> > > case. I then have to ask the submitter to provide a branch, or enough
> > > information to recreate a branch. Having base information (base-commit,
> > > prerequisite-patch-id, and possibly base-tree) would save me quite some
> > > time.
> > >
> > > I understand your concern about maintainers cherry-picking and sometimes
> > > introducing issues as a result. In that case I also prefer asking the
> > > submitter to rebase, retest, and resubmit. That's not what I want to use
> > > base information for, in my case it helps with the review process.
> >
> > 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 ?
My base is usually not in your or anyone else's tree...
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