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

[Laurent Pinchart]

On Mon, Oct 26, 2026 at 04:37:28PM +0100, Geert Uytterhoeven wrote:
> On Mon, 26 Oct 2026 at 15:53, Laurent Pinchart wrote:
> > On Mon, Oct 26, 2026 at 03:02:27PM +0100, Geert Uytterhoeven wrote:
> > > On Mon, 26 Oct 2026 at 11:48, Laurent Pinchart 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...
> >
> > Hence the prerequisite-patch-id and base tree information. Or do you
> > mean your base is not public at all, neither in the form of a branch
> > pushed to a public tree, nor as prerequisite patches sent to a public
> > list ?
> 
> Correct.

How am I supposed to review or apply something that depends on work that
is not public ?

-- 
Regards,

Laurent Pinchart