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

[Krzysztof Kozlowski <krzk@kernel.org>]

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?

> 
> 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.

> 
>> 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...


Best regards,
Krzysztof