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

["Theodore Tso" <tytso@mit.edu>]

On Tue, Oct 27, 2026 at 02:23:46PM -0500, Laurent Pinchart wrote:
> > The problem boils down to how to present work that touches multiple
> > target trees, and where some parts depend on other work that is
> > not yet finished. Do you post it as single series, so people get an
> > overview? Do you split it in multiple small series (which may still
> > have interdependencies), so everybody looses context?
> 
> There's no one-size-fits-them-all solution to this problem. What I want
> in those cases is information provided by the person posting the patches
> about the dependencies and where to find them. I think there's value in
> specifying that information in a machine-parseable way.

The problem is that "one size fits all" and "machine-parseable way"
are in tension with one another.  One approach might be that the
patche series fragments might be sent to different subsystem mailing
lists and reiewers, but the cover letter might include a pointer to a
unified git branch which has all of the patches touching all of the
different pieces.

Another approach might be to post it as a single series, but different
mailing lists and reviewers get cc'ed on the various patches in that
series --- and everyone gets cc'ed on the cover letter which also has
a pointer to the unified git branch.

A lot of this really depends on whether you are asking for reviews, or
whether you are asking people to apply the patch series in their
subsystem trees.  In the case where there are a large number of
interdependencies, they probably can't do that via patch series
anyway, and it might be easier just to get relevant ack'ed by and then
send to Linus with an explanation that you've gotten acks from all of
the relevant reviewers.

In truth, this case is actually pretty rare.  The more common case is
where there is a single set of changes that multiple patch series
might depend upon.  For example, there might be an set of iomap
changes which will go on one branch, and then various file systems
(xfs, ext4, btrfs, etc.) might pull in that common dependency branch
with the iomap changes, and then put their ext4 changes on top of
those.

In that case, what's important is not just the base commit id, but an
explanation of where to find that base commit.  Normally that just
goes in the cover letter, in human readable form, because I don't
think we have a lot of automation that tries to deal with that, as a
subsystem maintianer, reading the cover letter is just fine from my
perspective.  But if someone wants to propsoe extending the base
commit with a repo and branch or tag where the commit can be found, I
guess we could do that.

       	      	       	      		     	   - Ted