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

[Krzysztof Kozlowski <krzk@kernel.org>]

On 11/09/2025 13:04, Krzysztof Kozlowski wrote:
> Hi,
> 
> 
> I have noticed at least a few cases where sub-maintainers collect
> patches, but their trees are not included linux-next. Or their patches
> are not fed to linux-next.
> 
> I don’t see a good reason to keep valid, proper patches - collected by
> trusted sub-maintainers and intended for upstream submission - out of
> linux-next. If a sub-maintainer is trusted in collecting patches and
> sending them to the upstream maintainer, these commits should be visible
> in the linux-next.
> 
> I have occasionally asked sub-maintainers to add their trees to the
> linux-next, and sometimes this worked. In other cases it could not work
> for various reasons, e.g. workflow of the upstream maintainer or
> reluctance to share commits early. These reasons are what I would like
> to discuss and, hopefully, improve.
> 
> 
> 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.
> 
> 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?).
> 
> 
> 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.
2024... D'oh! I looked at wrong tag, thus wrong year. This case is a bit
trickier to investigate, especially if sub-maintainer rebases the tree
and there is no thank-you letters on mailing list, but to illustrate
that pattern in media:

commit 0fb275a28933989ef599d92bf0cc2c99b750ca9b
Author:     Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
AuthorDate: Mon Aug 25 12:30:26 2025 +0530
Commit:     Bryan O'Donoghue <bod@kernel.org>
CommitDate: Fri Sep 5 16:01:54 2025 +0100

and above commit appeared in next-20250911, so ~one week after being
applied to sub-maintainer tree is not so bad.


Best regards,
Krzysztof