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

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

On Thu, Oct 22, 2026 at 10:29:55AM +0200, Krzysztof Kozlowski wrote:
> On 22/10/2026 09:25, Eric Biggers 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.
> > 
> > linux-next changes every day, so "It's just linux-next" is ambiguous.
> > 
> > Without base-commit, the workaround ends up being to use the date the
> > patch was sent and various other information to try to guess a base
> > commit.  That's time-consuming and unreliable.
> 
> No, you just apply to the latest next. You don't guess. We speak about
> the case of reviewer, so person working with the kernel, thus probably
> having not-so-old linux-next available. If the next use as base is old
> it won't help you at all, because you might not even have it in your tree.

I don't test on linux-next, that causes way too much churn. I test
patches I review on top of their respective subsystem's tree, as that's
where they will eventually be applied.

-- 
Regards,

Laurent Pinchart