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

[Eric Biggers]

On Tue, Oct 27, 2026 at 03:31:36PM +0100, Krzysztof Kozlowski wrote:
> >> Since this step is pointless - it would be linux-next
> >> (assuming in the first place that this is what the author wanted here!)
> >> - it is a waste of time for me and potential resubmit of series, just to
> >> fulfill requirement which brings no benefits. So I have downside and I
> >> see no upside for my case, when you require the base.
> >>
> >> This might be affecting others as well, but now speaking about my
> >> workflow - I have a lot of independent cleanups, which I stack on top of
> >> each other, sometimes series, sometimes not, but stacking is important
> >> so when I run `make W=1` it passes.
> >>
> >> What's more important, I reject the entire reasoning/cause of this
> >> change, which claimed you cannot review and therefore accept such
> >> patches. It's simply not true.
> > 
> > That's not my claim.
> 
> That's the claim from commit msg. And wording should rather be "which
> claimed one cannot review".

Emailed patches include only 3 lines of context by default.  That's
simply not enough for a proper review in most cases.  For a proper
review patches usually have to be applied, which often fails especially
if it's an old patch.  (Caveat: as usual, the frequency of this varies
by subsystem.  So some people encounter them more than others.  Just
because you might not experience this much doesn't mean others don't...)

base-commit (and optional prerequisite-patch-id) can prevent that in
most cases.  That's the point.  And it helps for applying patches for
any other reason, like testing, or resuming work on on old patchset.

It seems like your concern is that people would bureaucratically ignore
patches without base-commit even when they apply cleanly to "something
obvious"?  That is not what I intended for this at all.  This is all
about getting more patches to include base tree information.

I also don't think your interpretation is consistent with the actual
commit message or diff of this patch.  Regardless, I'd also be glad to
clarify the wording.  Do you have any specific wording suggestions?

- Eric