Re: [MAINTAINERS SUMMIT] Hidden commits from next (aka why maintainers hoard them in backpack)

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

On Thu, Sep 11, 2025 at 02:47:23PM +0200, Krzysztof Kozlowski wrote:
> On 11/09/2025 14:27, Laurent Pinchart wrote:
> > On Thu, Sep 11, 2025 at 01:04:19PM +0200, Krzysztof Kozlowski wrote:
> >>
> >> Why is that a problem?
> >> ======================
> >> Patch was reviewed on the list day X and applied by the sub-maintainer.
> >> Then for two, three or four weeks, this patch is not being in the
> >> linux-next means:
> >> 1. Limited or no build bot coverage.
> >>
> >> 2. No actual integration testing, even if it is just spotting early
> >> merge conflicts.
> > 
> > This has prevented me from noticing an integration issue with DT
> > bindings and DT sources in at least one occasion, so I'm interested in
> > improving the process.
> 
> Ack
> 
> >> 3. No wide community testing.
> >>
> >> 4. Contributors cannot base their patchsets on linux-next for
> >> convenience, but need to find each sub-maintainer tree and pull it. For
> >> few cases (see further) these sub-maintainer trees are not documented in
> >> MAINTAINERS, so it is impossible for contributor to rebase on current
> >> maintainer's tree!
> >>
> >>
> >>
> >> Identifying the patches
> >> =======================
> >> There are two cases here for patches committed by sub-maintainers, but
> >> never fed to next:
> >> 1. The upstream maintainer took them via pull request.
> >> 2. The upstream maintainer rebased everything - changing commit date (to
> >> add their own Signed-off-by? otherwise why would you rebase a pull
> >> request from someone you trust?).
> > 
> > I've heard a maintainer saying that Linus doesn't like subsystem trees
> > to have lots of merges. Any help debunking that would be appreciated.
> 
> I think I was never corrected, nor were my upstream maintainers, so two
> levels of indentation is for sure not too much. And that would be the
> case for you, right? Your upstream is Hans, whose upstream is Linus?

Hans and Mauro, yes.

> > Linear histories have upsides, but rebasing causes pain. drm-misc is one
> > case of linear history with limited pain: with dozens (hundreds ?) of
> > committers, patches are pushed to drm-misc pretty much right away once
> > they're approved, and they end up in linux-next. Committers do not hoard
> > patches in their private trees for weeks or even days before pushing to
> > drm-misc. The linear history is in this case likely a good compromise:
> > it simplifies the workflow for committers, while not introducing rebases
> > down the line (the only rebase operations happen right away when a
> > committer picks a patch and loses the race with other committers to push
> > it to drm-misc).
> > 
> > For subsystems with workflows based on pull requests from
> > sub-maintainers, I say way more downsides than upsides in
> > cherry-picking/rebasing.
> 
> Plus rebasing looses the information about signed tags. When you send
> the pull request to your upstream with signed tags and this gets
> rebased, all the trust is purely on upstream maintainer. Your actual
> pull is visible only in SoBs, but not itself.

It also possibly loses the information about what base the commits have
been tested on. That's not relevant for patches I pick from the list,
but for work that I author myself and test before sending the pull
request, that information is lost.

> >> Short stats for case (1) - no rebasing
> >> ======================================
> >>
> >> I collected commits present in today's linux-next, but not present in
> >> ~two weeks ago. These are the commits which appeared for broad testing
> >> in the last two weeks.
> >>
> >> Then I dropped from above set all commits with commit date newer than
> >> the next two weeks ago.
> >>
> >> This gives us set of commits:
> >> 1. Which were committed some time ago, like a month ago,
> >> 2. But they appeared in the linux-next only recently or were rebased.
> >> 3. Then a manual look by subject (not automated yet) to be sure commit
> >> was not rebased.
> >>
> >> Where were these commits? Why maintainers hoard them instead of
> >> releasing to linux-next?
> >>
> >> Currently that is around:
> >> git rev-list --before=2025-08-27 next-20250911 ^next-20250829 | wc -l
> >> 133
> >>
> >> `git show --no-patch --format=fuller` on above list
> >>
> >> And here is the example output of such commits still not in the
> >> next-20250829:
> >>
> >> Author:     John Harrison <John.C.Harrison@Intel.com>
> >> AuthorDate: Fri Jun 13 20:02:22 2025 -0700
> >> Commit:     Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> >> CommitDate: Thu Jul 3 14:05:10 2025 -0700
> >>
> >> Author:     Arnd Bergmann <arnd@arndb.de>
> >> AuthorDate: Thu Aug 7 09:21:28 2025 +0200
> >> Commit:     Oliver Upton <oliver.upton@linux.dev>
> >> CommitDate: Fri Aug 8 01:28:57 2025 -0700
> >>
> >> commit 0c6b24d70da21201ed009a2aca740d2dfddc7ab5
> >> Author:     Jason-JH Lin <jason-jh.lin@mediatek.com>
> >> AuthorDate: Mon Jul 28 10:48:50 2025 +0800
> >> Commit:     Chun-Kuang Hu <chunkuang.hu@kernel.org>
> >> CommitDate: Wed Aug 13 23:50:06 2025 +0000
> >>
> >>
> >> Short stats for case (2) - rebasing
> >> ===================================
> >> I don’t have statistics for these cases, because sub-maintainers’ trees
> >> are not in linux-next, and the upstream maintainer changes the commit
> >> date during rebasing.
> >>
> >> But such cases do exist (I dug them out, even though maintainer trees
> >> are not listed in MAINTAINERS file but pull requests are on the lists):
> >>
> >> Author:     Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> >> AuthorDate: Thu Aug 8 22:41:02 2024 +0200
> >> Commit:     Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> >> CommitDate: Wed Aug 14 16:42:57 2024 +0300
> >>
> >> Above commit is not in linux-next still, even though it was committed
> >> month ago.
> > 
> > Can you provide the commit ID ? It's hard to check what happened without that.
> 
> Apologies, that was my brain looking at wrong tag. All is good from your
> side. See my response with D'oh...

-- 
Regards,

Laurent Pinchart