> I don't think the mechanics of how patches get moved about has a huge
> impact on the effort involved

50:50, in my case.

> - trust and delegation make much more of a difference.  I've got
> several areas where other people are reviewing large volumes of
> patches before I ever see them,

This is also true for me. When I called out for per-driver maintainers,
this made the flood of patches bearable. All of the driver maintainers
prefer to review only, though, and let me handle the rest. This is
totally fine with me. I'd likely lose some reviewers if I force to them
to provide me with separate branches.

The other part is: a few months ago Andi Shyti took over the maintenance
of the I2C controller patches. He updates patchwork, handles
dependencies, decides on for-current and for-next, writes pull
requests... That frees so much time that I have actually time left to
work on the core code again and give high-level guidance how to tackle
problems. So, this really helps as well.

That basically boils down to what I said last year at the Maintainer
Summit: In some parts of the Kernel, there is no flexibility to redesign
the hierarchy. The limited amount of people interested in maintaining
and their needs already shape the workflow. And for me, this is also the
primary reason why the merge-tree looks so flat.