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

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

[Krzysztof Kozlowski]

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.

Just a friendly note, Laurent, I appreciate your work and I do not want
to point that you committed it incorrectly. In the contrary - your
commit is right, but your upstream maintainer stops you from including
this in linux-next. My aim here is only to discuss and improve the process.


Terminology
===========
1. Sub-maintainer: A person who collects (applies) patches and sends
them via pull request to the upstream maintainer.

2. Upstream maintainer: A person who collects patches from contributors
and pull requests from sub-maintainers, and then sends everything to
Linus (or another upstream maintainer).



Best regards,
Krzysztof

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

[Krzysztof Kozlowski]

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

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2193 bytes --]

On Thu, Sep 11, 2025 at 01:04:19PM +0200, Krzysztof Kozlowski wrote:

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

Yes, this is especially frustrating when it's fixes trees and you end up
with breakage in -next for a week or whatever while you wait for a fix
to make it's way to the upstream maintainer's tree.  If that's something
like a boot or build break it can obscure a bunch of other testing, not
just the issue itself, which is even less helpful.  Where this is a
problem I really don't understand the reasoning of the relevant
maintainers.

Mostly people are totally happy to put their trees in -next and either
forgot or simply weren't aware they could do it.

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

There is the case where people send things to the list as a patch series
with a pull request in the cover letter, the stuff in the pull request
hasn't actually been reviewed yet.  Not sure how common that is, I have
discussed a workflow like that with some of the people who send to me
but I'm not actually doing it myself.  None of the cases you found
immediately look like that.

You might also catch cases where there was a pre-next test phase, that
lasting two weeks should be very unusual though.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Jiri Kosina]

On Thu, 11 Sep 2025, Krzysztof Kozlowski wrote:

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

Hm, why would that imply that they never make to linux-next though?

I always keep multiple topic branches that are queued for upcoming merge 
window, and it doesn't really matter whether they came in from pull 
request of whether I have created it myself.

And all those branches then merge into for-next, which linux-next is 
consuming.

I don't see how the fact that (part of) topic branch came in via pull 
request would make any difference ... ?

Thanks,

-- 
Jiri Kosina
SUSE Labs

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

[Krzysztof Kozlowski]

On 11/09/2025 14:06, Jiri Kosina wrote:
> On Thu, 11 Sep 2025, Krzysztof Kozlowski wrote:
> 
>> 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.
> 
> Hm, why would that imply that they never make to linux-next though?

I was not precise. The commits end in next once they reach upstream
maintainer. I wanted to say they are never in the next while being only
in sub-maintainer's tree.

> 
> I always keep multiple topic branches that are queued for upcoming merge 
> window, and it doesn't really matter whether they came in from pull 
> request of whether I have created it myself.
> 
> And all those branches then merge into for-next, which linux-next is 
> consuming.

Yep, that's how it should be.

> 
> I don't see how the fact that (part of) topic branch came in via pull 
> request would make any difference ... ?



Best regards,
Krzysztof

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

[Laurent Pinchart]

On Thu, Sep 11, 2025 at 01:04:19PM +0200, 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.

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.

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

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.

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

> Just a friendly note, Laurent, I appreciate your work and I do not want
> to point that you committed it incorrectly. In the contrary - your
> commit is right, but your upstream maintainer stops you from including
> this in linux-next. My aim here is only to discuss and improve the process.

I would be happy to have my tree included in linux-next. I'm worried
that the fact that the media subsystem cherry-picks my pull requests
instead of merging them would cause issues though. Am I worrying
needlessly, or is that a real issue ?

> Terminology
> ===========
> 1. Sub-maintainer: A person who collects (applies) patches and sends
> them via pull request to the upstream maintainer.
> 
> 2. Upstream maintainer: A person who collects patches from contributors
> and pull requests from sub-maintainers, and then sends everything to
> Linus (or another upstream maintainer).

There's a bit of overlap between the two catagories in your definitions
with the "or another upstream maintainer" part in the second definition.

-- 
Regards,

Laurent Pinchart

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

[Bartosz Golaszewski]

On Thu, 11 Sept 2025 at 14:27, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> > Just a friendly note, Laurent, I appreciate your work and I do not want
> > to point that you committed it incorrectly. In the contrary - your
> > commit is right, but your upstream maintainer stops you from including
> > this in linux-next. My aim here is only to discuss and improve the process.
>
> I would be happy to have my tree included in linux-next. I'm worried
> that the fact that the media subsystem cherry-picks my pull requests
> instead of merging them would cause issues though. Am I worrying
> needlessly, or is that a real issue ?

Stephen Rothwell will send you automated emails about duplicate
commits being present in linux-next - one coming from your downstream
and one rebased in your upstream maintainer's tree.

Bartosz

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

[Laurent Pinchart]

On Thu, Sep 11, 2025 at 02:31:23PM +0200, Bartosz Golaszewski wrote:
> On Thu, 11 Sept 2025 at 14:27, Laurent Pinchart wrote:
> >
> > > Just a friendly note, Laurent, I appreciate your work and I do not want
> > > to point that you committed it incorrectly. In the contrary - your
> > > commit is right, but your upstream maintainer stops you from including
> > > this in linux-next. My aim here is only to discuss and improve the process.
> >
> > I would be happy to have my tree included in linux-next. I'm worried
> > that the fact that the media subsystem cherry-picks my pull requests
> > instead of merging them would cause issues though. Am I worrying
> > needlessly, or is that a real issue ?
> 
> Stephen Rothwell will send you automated emails about duplicate
> commits being present in linux-next - one coming from your downstream
> and one rebased in your upstream maintainer's tree.

So the question is how to redirect Stephen's complaints to the person
who is responsible for the issue in the first place :-)

-- 
Regards,

Laurent Pinchart

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

[Geert Uytterhoeven]

Hi Laurent,

On Thu, 11 Sept 2025 at 14:27, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thu, Sep 11, 2025 at 01:04:19PM +0200, Krzysztof Kozlowski wrote:
> 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).

And after that, several of them are cherry-picked to a fixes branch...

> > Just a friendly note, Laurent, I appreciate your work and I do not want
> > to point that you committed it incorrectly. In the contrary - your
> > commit is right, but your upstream maintainer stops you from including
> > this in linux-next. My aim here is only to discuss and improve the process.
>
> I would be happy to have my tree included in linux-next. I'm worried
> that the fact that the media subsystem cherry-picks my pull requests
> instead of merging them would cause issues though. Am I worrying
> needlessly, or is that a real issue ?

I think you would start receiving "same commit present in multiple
trees with different commit IDs"-emails from sfr...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Johannes Berg]

On Thu, 2025-09-11 at 15:27 +0300, Laurent Pinchart wrote:
> 
> > Just a friendly note, Laurent, I appreciate your work and I do not want
> > to point that you committed it incorrectly. In the contrary - your
> > commit is right, but your upstream maintainer stops you from including
> > this in linux-next. My aim here is only to discuss and improve the process.
> 
> I would be happy to have my tree included in linux-next. I'm worried
> that the fact that the media subsystem cherry-picks my pull requests
> instead of merging them would cause issues though. Am I worrying
> needlessly, or is that a real issue ?

If they end up in both trees with different commit IDs it'll get flagged
(and you'll get an email about it), but presumably you'll drop them from
your trees pretty much as soon as that happens, so it should be fine
afaict.

johannes

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

[Laurent Pinchart]

On Thu, Sep 11, 2025 at 02:35:38PM +0200, Johannes Berg wrote:
> On Thu, 2025-09-11 at 15:27 +0300, Laurent Pinchart wrote:
> > 
> > > Just a friendly note, Laurent, I appreciate your work and I do not want
> > > to point that you committed it incorrectly. In the contrary - your
> > > commit is right, but your upstream maintainer stops you from including
> > > this in linux-next. My aim here is only to discuss and improve the process.
> > 
> > I would be happy to have my tree included in linux-next. I'm worried
> > that the fact that the media subsystem cherry-picks my pull requests
> > instead of merging them would cause issues though. Am I worrying
> > needlessly, or is that a real issue ?
> 
> If they end up in both trees with different commit IDs it'll get flagged
> (and you'll get an email about it), but presumably you'll drop them from
> your trees pretty much as soon as that happens, so it should be fine
> afaict.

If it happens as an accident, sure, but I don't think it's a very nice
mode of operation as a standard process.

-- 
Regards,

Laurent Pinchart

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

[Krzysztof Kozlowski]

On 11/09/2025 14:33, Laurent Pinchart wrote:
> On Thu, Sep 11, 2025 at 02:31:23PM +0200, Bartosz Golaszewski wrote:
>> On Thu, 11 Sept 2025 at 14:27, Laurent Pinchart wrote:
>>>
>>>> Just a friendly note, Laurent, I appreciate your work and I do not want
>>>> to point that you committed it incorrectly. In the contrary - your
>>>> commit is right, but your upstream maintainer stops you from including
>>>> this in linux-next. My aim here is only to discuss and improve the process.
>>>
>>> I would be happy to have my tree included in linux-next. I'm worried
>>> that the fact that the media subsystem cherry-picks my pull requests
>>> instead of merging them would cause issues though. Am I worrying
>>> needlessly, or is that a real issue ?
>>
>> Stephen Rothwell will send you automated emails about duplicate
>> commits being present in linux-next - one coming from your downstream
>> and one rebased in your upstream maintainer's tree.
> 
> So the question is how to redirect Stephen's complaints to the person
> who is responsible for the issue in the first place :-)


That's a real issue, so your worrying is correct, even if Stephen adds
exception for certain trees causing commit duplicates.

If commit appears twice in linux-next people might put the wrong one in
"Fixes" or "commit SHA" references. Duplicate commit is a redundant
information and waste of people's time (vide discussion about Link: tags).


I think DRM is even weirder here - already discussed in the past - where
they cherry-pick commits between branches causing duplicates and
reference other commit while not feeding them to linux-next promptly. I
still remember the one RC pull request from Intel to DRM which had
commits like:

    Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid ...
    (cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417)
    Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

and when on linux-next you try to figure our what was the source here,
you get:
$ git show 97b6784753da06d9d40232328efc5c5367e53417
fatal: bad object 97b6784753da06d9d40232328efc5c5367e53417
(Tried with repo having several maintainer repos and the linux-next THAT
time; now it works...)

I also remember Linus pointing out some of these duplicates on mailing list.


Best regards,
Krzysztof

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

[Krzysztof Kozlowski]

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

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 821 bytes --]

On Thu, Sep 11, 2025 at 03:36:24PM +0300, Laurent Pinchart wrote:
> On Thu, Sep 11, 2025 at 02:35:38PM +0200, Johannes Berg wrote:

> > If they end up in both trees with different commit IDs it'll get flagged
> > (and you'll get an email about it), but presumably you'll drop them from
> > your trees pretty much as soon as that happens, so it should be fine
> > afaict.

> If it happens as an accident, sure, but I don't think it's a very nice
> mode of operation as a standard process.

Yeah, those emails currently involve a manual step in sending so either
that gets automated (possibly by flagging the tree as "this is supposed
to happen", dunno might be too much work?) or the person doing the
sending might get fed up.  I'll try to take a look at the scripting
during Stephen's upcoming holiday but no guarantees.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Sasha Levin]

On Thu, Sep 11, 2025 at 01:04:19PM +0200, 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!

This topic seems to come up on an annual basis :)

As a follow up to last year's discussion[1] I wrote a bot[2] that is able to
analyze pull requests and respond with statistics about how long commits spent
in -next as well as on the mailing lists. An example of the reports it produces
is available here[3].

I haven't ended up receiving signal from Linus that it's useful and not a waste
of his time, so I stopped sending these mails out.



[1] https://lore.kernel.org/all/ZyAUO0b3z_f_kVnj@sashalap/
[2] https://git.kernel.org/pub/scm/linux/kernel/git/sashal/next-analysis.git/
[3] https://lore.kernel.org/all/Zxf3vp82MfPTWNLx@sashalap/

-- 
Thanks,
Sasha

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

[Laurent Pinchart]

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

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

[Greg KH]

On Thu, Sep 11, 2025 at 02:42:47PM +0200, Krzysztof Kozlowski wrote:
> On 11/09/2025 14:33, Laurent Pinchart wrote:
> > On Thu, Sep 11, 2025 at 02:31:23PM +0200, Bartosz Golaszewski wrote:
> >> On Thu, 11 Sept 2025 at 14:27, Laurent Pinchart wrote:
> >>>
> >>>> Just a friendly note, Laurent, I appreciate your work and I do not want
> >>>> to point that you committed it incorrectly. In the contrary - your
> >>>> commit is right, but your upstream maintainer stops you from including
> >>>> this in linux-next. My aim here is only to discuss and improve the process.
> >>>
> >>> I would be happy to have my tree included in linux-next. I'm worried
> >>> that the fact that the media subsystem cherry-picks my pull requests
> >>> instead of merging them would cause issues though. Am I worrying
> >>> needlessly, or is that a real issue ?
> >>
> >> Stephen Rothwell will send you automated emails about duplicate
> >> commits being present in linux-next - one coming from your downstream
> >> and one rebased in your upstream maintainer's tree.
> > 
> > So the question is how to redirect Stephen's complaints to the person
> > who is responsible for the issue in the first place :-)
> 
> 
> That's a real issue, so your worrying is correct, even if Stephen adds
> exception for certain trees causing commit duplicates.
> 
> If commit appears twice in linux-next people might put the wrong one in
> "Fixes" or "commit SHA" references. Duplicate commit is a redundant
> information and waste of people's time (vide discussion about Link: tags).
> 
> 
> I think DRM is even weirder here - already discussed in the past - where
> they cherry-pick commits between branches causing duplicates and
> reference other commit while not feeding them to linux-next promptly. I
> still remember the one RC pull request from Intel to DRM which had
> commits like:
> 
>     Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>     Link: https://patchwork.freedesktop.org/patch/msgid ...
>     (cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417)
>     Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> 
> and when on linux-next you try to figure our what was the source here,
> you get:
> $ git show 97b6784753da06d9d40232328efc5c5367e53417
> fatal: bad object 97b6784753da06d9d40232328efc5c5367e53417
> (Tried with repo having several maintainer repos and the linux-next THAT
> time; now it works...)
> 
> I also remember Linus pointing out some of these duplicates on mailing list.

I've pointed out the drm "mess" many times, it drives me crazy
attempting to track stuff being properly backported to stable trees all
the time...

thanks,

greg k-h

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

[James Bottomley]

On Thu, 2025-09-11 at 14:06 +0200, Jiri Kosina wrote:
> On Thu, 11 Sep 2025, Krzysztof Kozlowski wrote:
> 
> > 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.
> 
> Hm, why would that imply that they never make to linux-next though?
> 
> I always keep multiple topic branches that are queued for upcoming
> merge window, and it doesn't really matter whether they came in from
> pull request of whether I have created it myself.
> 
> And all those branches then merge into for-next, which linux-next is 
> consuming.
> 
> I don't see how the fact that (part of) topic branch came in via pull
> request would make any difference ... ?

Yes, this is what I see too ...

The requirement from Linus for merge is usually incubation in -next, so
there are very few pull requests that haven't been at least a few days
in -next.  So what is your complaint?  That the incubation period is
too short or that every patch should be in -next as soon as it hits any
maintainer tree rather that submaintainers relying on the overall
maintainer to do the incubation for them?

Regards,

James

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1241 bytes --]

On Thu, Sep 11, 2025 at 03:27:11PM +0300, Laurent Pinchart wrote:
> On Thu, Sep 11, 2025 at 01:04:19PM +0200, Krzysztof Kozlowski wrote:

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

AIUI it's a quality of merges issue rather than a number of merges
issue, if the merge commits all have commit messages that convey useful
information about something that makes sense then you should be fine.
If the merge commits are all just default messages not so much.  Things
like taking a pull request with a descriptive commit like the cover
letter for the merge hopefully do have some purpose and a useful commit
message.  

The quantity thing comes up because a common way you end up with a lot
of merges is automation which tends to also imply lacking changelogs and
motivation.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]

On Thu, Sep 11, 2025 at 09:18:05AM -0400, James Bottomley wrote:
> On Thu, 2025-09-11 at 14:06 +0200, Jiri Kosina wrote:
> > On Thu, 11 Sep 2025, Krzysztof Kozlowski wrote:

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

> > Hm, why would that imply that they never make to linux-next though?

...

> > I don't see how the fact that (part of) topic branch came in via pull
> > request would make any difference ... ?

> Yes, this is what I see too ...

> The requirement from Linus for merge is usually incubation in -next, so
> there are very few pull requests that haven't been at least a few days
> in -next.  So what is your complaint?  That the incubation period is
> too short or that every patch should be in -next as soon as it hits any
> maintainer tree rather that submaintainers relying on the overall
> maintainer to do the incubation for them?

One pattern you see with trees that do this is that some bug is found in
-next, the bug is fixed and the patch applied but if the patch is
applied to a tree that isn't in -next you still see the bug in -next
until the pull request to the upstream tree goes through.  Any
incubation that the subtree does before sending their pull request, or
delay in taking the pull request from the subtree, shows up in
additional time that the bug is visible in -next.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Steven Rostedt]

On Thu, 11 Sep 2025 14:40:45 +0100
Mark Brown <broonie@kernel.org> wrote:

> > 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.  
> 
> AIUI it's a quality of merges issue rather than a number of merges
> issue, if the merge commits all have commit messages that convey useful
> information about something that makes sense then you should be fine.
> If the merge commits are all just default messages not so much.  Things
> like taking a pull request with a descriptive commit like the cover
> letter for the merge hopefully do have some purpose and a useful commit
> message.  
> 
> The quantity thing comes up because a common way you end up with a lot
> of merges is automation which tends to also imply lacking changelogs and
> motivation.

Basically a merge commit should be no different than any other commit. It
should have a purpose and that purpose should be described in the merge's
change log just like every other commit has its purpose described in their
own.

I now have several topic branches, and I try hard to avoid merges as they
tend to make my pull requests more complex. But every so often, I have a
patch that comes in that is required for work in two of my existing topic
branches. This is a case where one change is required for two topic
branches to continue more work.

In these rare events, I will apply the change to one of the topic branches,
then merge it into the other with a detailed explanation to why I needed to
do that merge.

Linus hasn't complained about it, so I'm guessing that's the correct thing
to do.

-- Steve

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

[James Bottomley]

[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]

On Thu, 2025-09-11 at 14:49 +0100, Mark Brown wrote:
> On Thu, Sep 11, 2025 at 09:18:05AM -0400, James Bottomley wrote:
[...]
> > The requirement from Linus for merge is usually incubation in -
> > next, so there are very few pull requests that haven't been at
> > least a few days in -next.  So what is your complaint?  That the
> > incubation period is too short or that every patch should be in -
> > next as soon as it hits any maintainer tree rather that
> > submaintainers relying on the overall maintainer to do the
> > incubation for them?
> 
> One pattern you see with trees that do this is that some bug is found
> in -next, the bug is fixed and the patch applied but if the patch is
> applied to a tree that isn't in -next you still see the bug in -next
> until the pull request to the upstream tree goes through.  Any
> incubation that the subtree does before sending their pull request,
> or delay in taking the pull request from the subtree, shows up in
> additional time that the bug is visible in -next.

In theory a fix to a pulled commit, whether separate or rebased, should
be treated like a bug fix and go up with speed, so is this simply a
missing rule (or encouragement) for a tree not in -next?

Regards,

James


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1140 bytes --]

On Thu, Sep 11, 2025 at 11:32:10AM -0400, James Bottomley wrote:
> On Thu, 2025-09-11 at 14:49 +0100, Mark Brown wrote:
> > On Thu, Sep 11, 2025 at 09:18:05AM -0400, James Bottomley wrote:

> > One pattern you see with trees that do this is that some bug is found
> > in -next, the bug is fixed and the patch applied but if the patch is
> > applied to a tree that isn't in -next you still see the bug in -next
> > until the pull request to the upstream tree goes through.  Any
> > incubation that the subtree does before sending their pull request,
> > or delay in taking the pull request from the subtree, shows up in
> > additional time that the bug is visible in -next.

> In theory a fix to a pulled commit, whether separate or rebased, should
> be treated like a bug fix and go up with speed, so is this simply a
> missing rule (or encouragement) for a tree not in -next?

Partly, yes, but the bug isn't always directly in the tree where the fix
is going so it can be a bit less clear and sometimes the delay is on the
pull side (eg, due to holidays or whatever).  It's a lot simpler to just
put the tree in -next.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[James Bottomley]

[-- Attachment #1: Type: text/plain, Size: 1550 bytes --]

On Thu, 2025-09-11 at 17:02 +0100, Mark Brown wrote:
> On Thu, Sep 11, 2025 at 11:32:10AM -0400, James Bottomley wrote:
> > On Thu, 2025-09-11 at 14:49 +0100, Mark Brown wrote:
> > > On Thu, Sep 11, 2025 at 09:18:05AM -0400, James Bottomley wrote:
> 
> > > One pattern you see with trees that do this is that some bug is
> > > found in -next, the bug is fixed and the patch applied but if the
> > > patch is applied to a tree that isn't in -next you still see the
> > > bug in -next until the pull request to the upstream tree goes
> > > through.  Any incubation that the subtree does before sending
> > > their pull request, or delay in taking the pull request from the
> > > subtree, shows up in additional time that the bug is visible in -
> > > next.
> 
> > In theory a fix to a pulled commit, whether separate or rebased,
> > should be treated like a bug fix and go up with speed, so is this
> > simply a missing rule (or encouragement) for a tree not in -next?
> 
> Partly, yes, but the bug isn't always directly in the tree where the
> fix is going so it can be a bit less clear and sometimes the delay is
> on the pull side (eg, due to holidays or whatever).  It's a lot
> simpler to just put the tree in -next.

There is a downside to putting the upper and lower trees in -next,
particularly if they're out of sync like you describe above in that it
will likely cause a conflict.  Now Stephen usually resolves these but
it's going to cause him way more problems if we adopt this approach.

Regards,

James


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 968 bytes --]

On Thu, Sep 11, 2025 at 12:11:46PM -0400, James Bottomley wrote:
> On Thu, 2025-09-11 at 17:02 +0100, Mark Brown wrote:

> > Partly, yes, but the bug isn't always directly in the tree where the
> > fix is going so it can be a bit less clear and sometimes the delay is
> > on the pull side (eg, due to holidays or whatever).  It's a lot
> > simpler to just put the tree in -next.

> There is a downside to putting the upper and lower trees in -next,
> particularly if they're out of sync like you describe above in that it
> will likely cause a conflict.  Now Stephen usually resolves these but
> it's going to cause him way more problems if we adopt this approach.

It's not a particularly new approach, it's pretty standard at this
point - the situations where it doesn't happen are more the outliers.
I'm not sure conflicts are a particularly big issue, the stuff I was
thinking about above was more latent bugs being exposed like race
conditions.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Dan Carpenter]

On Thu, Sep 11, 2025 at 01:05:36PM +0100, Mark Brown wrote:
> On Thu, Sep 11, 2025 at 01:04:19PM +0200, Krzysztof Kozlowski wrote:
> 
> > 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.
> 
> Yes, this is especially frustrating when it's fixes trees and you end up
> with breakage in -next for a week or whatever while you wait for a fix
> to make it's way to the upstream maintainer's tree.

One thing that would help is if someone breaks linux-next and then post
the fix but also let us know when it will be merged into linux-next.
Sometimes people fix the patch silently without responding to the bug
report.  Or they post the patch and we assume it's going to be merged
the next day but they want to test it for an extra day or two first.

regards,
dan carpenter

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

[Laurent Pinchart]

Hi Steve,

On Thu, Sep 11, 2025 at 10:25:06AM -0400, Steven Rostedt wrote:
> On Thu, 11 Sep 2025 14:40:45 +0100 Mark Brown wrote:
> 
> > > 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.  
> > 
> > AIUI it's a quality of merges issue rather than a number of merges
> > issue, if the merge commits all have commit messages that convey useful
> > information about something that makes sense then you should be fine.
> > If the merge commits are all just default messages not so much.  Things
> > like taking a pull request with a descriptive commit like the cover
> > letter for the merge hopefully do have some purpose and a useful commit
> > message.  
> > 
> > The quantity thing comes up because a common way you end up with a lot
> > of merges is automation which tends to also imply lacking changelogs and
> > motivation.
> 
> Basically a merge commit should be no different than any other commit. It
> should have a purpose and that purpose should be described in the merge's
> change log just like every other commit has its purpose described in their
> own.
> 
> I now have several topic branches, and I try hard to avoid merges as they
> tend to make my pull requests more complex. But every so often, I have a
> patch that comes in that is required for work in two of my existing topic
> branches. This is a case where one change is required for two topic
> branches to continue more work.

Do you then send an individual pull request for each topic branch to
Linus ?

What if one of those topic branches had to aggregate patches from, let's
say, 10 different series from 10 contributors who each sent you a pull
request ? Would you merge them or cherry-pick them ?

> In these rare events, I will apply the change to one of the topic branches,
> then merge it into the other with a detailed explanation to why I needed to
> do that merge.
> 
> Linus hasn't complained about it, so I'm guessing that's the correct thing
> to do.

-- 
Regards,

Laurent Pinchart

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

[Steven Rostedt]

On Thu, 11 Sep 2025 22:29:14 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:

> > I now have several topic branches, and I try hard to avoid merges as they
> > tend to make my pull requests more complex. But every so often, I have a
> > patch that comes in that is required for work in two of my existing topic
> > branches. This is a case where one change is required for two topic
> > branches to continue more work.  
> 
> Do you then send an individual pull request for each topic branch to
> Linus ?

Yes I do. Linus suggested it. I use to keep everything in a single branch,
but when Linus had an issue with one aspect of the pull request, it caused
me to rebase the entire thing. That's when Linus said I needed to break up
my changes into different topics so that if he had an issue with one, it
wouldn't stop the rest from getting in unmodified.

> 
> What if one of those topic branches had to aggregate patches from, let's
> say, 10 different series from 10 contributors who each sent you a pull
> request ? Would you merge them or cherry-pick them ?

Currently, the only pull requests I take are separate topic branches where
the merge usually ends up being a simple fast forward. Most of my updates
come from patches that I just pull into my topic branches directly from
patchwork.

I likely don't have the complexity of DRM.

But looking more at the tip tree, which is much more complex than my own,
which also has several topic branches. They merge in branches from others
via pull requests, just like Linus would from us. They don't cherry-pick
nor rebase, unless its patches from the mailing list. I believe Linus is OK
with that workflow.

-- Steve

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

[Dan Carpenter]

On Thu, Sep 11, 2025 at 02:42:47PM +0200, Krzysztof Kozlowski wrote:
> I think DRM is even weirder here - already discussed in the past - where
> they cherry-pick commits between branches causing duplicates and
> reference other commit while not feeding them to linux-next promptly. I
> still remember the one RC pull request from Intel to DRM which had
> commits like:
> 
>     Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>     Link: https://patchwork.freedesktop.org/patch/msgid ...
>     (cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417)
>     Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> 
> and when on linux-next you try to figure our what was the source here,
> you get:
> $ git show 97b6784753da06d9d40232328efc5c5367e53417
> fatal: bad object 97b6784753da06d9d40232328efc5c5367e53417
> (Tried with repo having several maintainer repos and the linux-next THAT
> time; now it works...)

Yeah.  There is the issue of you have a Fixes tag but can't figure out
which commit the Fixes tag is referencing.  And then there is the
reverse where you backporting a patch and you want to see if there are
any Fixes for that commit.  Duplicated hashes messes up the search
both ways.

regards,
dan carpenter

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

[Vlastimil Babka]

On 9/11/25 16:25, Steven Rostedt wrote:
> On Thu, 11 Sep 2025 14:40:45 +0100
> Mark Brown <broonie@kernel.org> wrote:
> 
> I now have several topic branches, and I try hard to avoid merges as they
> tend to make my pull requests more complex. But every so often, I have a
> patch that comes in that is required for work in two of my existing topic
> branches. This is a case where one change is required for two topic
> branches to continue more work.
> 
> In these rare events, I will apply the change to one of the topic branches,
> then merge it into the other with a detailed explanation to why I needed to
> do that merge.

Could you alternatively put the commit in a shared base of the two topic
branches, and thus avoid the merging? Or it is a case that you don't want to
rebase (at the moment because merge window is near, or ever?), or the change
can't be moved ahead of the other work in those topic branches?

> Linus hasn't complained about it, so I'm guessing that's the correct thing
> to do.
> 
> -- Steve
> 

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

[Krzysztof Kozlowski]

On 11/09/2025 14:49, Sasha Levin wrote:
> On Thu, Sep 11, 2025 at 01:04:19PM +0200, Krzysztof Kozlowski wrote:
>> 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!
> 
> This topic seems to come up on an annual basis :)
> 
> As a follow up to last year's discussion[1] I wrote a bot[2] that is able to
> analyze pull requests and respond with statistics about how long commits spent
> in -next as well as on the mailing lists. An example of the reports it produces
> is available here[3].

Oh, I missed that, these are nice!

> 
> I haven't ended up receiving signal from Linus that it's useful and not a waste
> of his time, so I stopped sending these mails out.


Honestly, I have a feeling that importance of this topic a bit depends
where do you look. Or where do you put your fingers. I work a lot with
multiple subsystems, although 99% of them around drivers, with frequent
inter-dependencies and cross-tree interactions. And by "work" I mean as
submitting patches and as a maintainer.

The best example here is the SoC DTS (Devicetree sources, so
arch/*/boot/dts/*) which is supposed to be completely independent of
actual drivers. Independent in a meaning it must go via different tree
(SoC tree) and never mixed or actually depending on the drivers, while
of course the driver implementation is necessary for entire thing to
work for the final user. That's by design.

I found for everything around me extremely important that accepted
patches reach linux-next as fast as possible. I found also similar
voices in the this email thread, so I am not alone in this judgment.

I can also imagine that if one does not deal ever with patchsets
touching multiple subsystems or does not have upstream/downstream
maintainership model, things are a bit simpler.

But really for these many things around me, commits not being in the
next is a significant pain (and appearing in next 1 week before merge
window does not count, because it is already too late for me to do
anything, since my upstream maintainers partially closes their tree
around rc6-rc7).


Best regards,
Krzysztof

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

[Steven Rostedt]

On Fri, 12 Sep 2025 11:52:18 +0200
Vlastimil Babka <vbabka@suse.cz> wrote:

> > In these rare events, I will apply the change to one of the topic branches,
> > then merge it into the other with a detailed explanation to why I needed to
> > do that merge.  
> 
> Could you alternatively put the commit in a shared base of the two topic
> branches, and thus avoid the merging? Or it is a case that you don't want to
> rebase (at the moment because merge window is near, or ever?), or the change
> can't be moved ahead of the other work in those topic branches?

Once I start pushing changes to linux-next, I try to avoid rebasing. That's
because my changes have already been tested, and others may be building on
top of them. In these rare cases, there's changes that are added to two
topic branches where a single change may be needed for both. Or more
realistically, a change will affect two topic branches (like a common
function that has its prototype changed. I may change it in one branch, and
then the other branch needs to use it too).

In these rare cases, I just add the change and merge it to prevent rebasing.

I also wait until the later rc releases to start pushing to linux-next to
limit these conflicts. I try to push around -rc4, but I'm a bit late, and
I'm going to be pushing around -rc5 and -rc6 this round :-/

-- Steve