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

[Krzysztof Kozlowski <krzk@kernel.org>]

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