Re: Policy regarding linux-next only changes

[Tetsuo Handa]

On 2026/07/27 2:49, Mark Brown wrote:
> On Sat, Jul 25, 2026 at 12:44:17PM +0900, Tetsuo Handa wrote:
> 
>> Excuse me, but what does "successfully unit tested" mean? Broken patches
>> that do not build, or trigger oops by just "/bin/cat" _are_ arriving at
>> linux-next tree, which in turn preventing continuous testing by syzbot.
> 
> You're supposed to make some reasonable effort to ensure that things
> work, if you break things badly enough and pay little enough attention
> your tree will get kicked.  To even get merged in -next on a given day a
> tree has to build in some of the more common configurations, and not
> break KUnit.  It's not expected that everything will be perfect, people
> can't be reasonably expected to to test all possible configurations - a
> big part of the point of -next is to pool coverage - but it's expected
> that people will be making a reasonable effort.

You and I are talking about different topics.

You are saying that I should not submit patches that break linux-next.
I am saying that maintainers are submitting patches that break linux-next
(and then stop responding after a breakage was found in linux-next).

Some maintainers respond quickly (e.g. remove problematic commits from the tree)
when syzbot sends a report that there was a build failure or boot failure with
linux-next kernel, but other maintainers respond very slowly.

For the latter example, syzbot is still using next-20260714 because a maintainer
who should accept/reject https://lkml.kernel.org/r/al1pElMQZsDfpAYI@michalis-linux
is not responding. As a result, syzbot is unable to test changes made between
next-20260714 and next-20260726.

Since one of purposes for linux-next.git is "find bugs before bugs reach linux.git",
being unable to follow daily next-YYYYMMDD is annoying. For example,
https://lkml.kernel.org/r/1a9f53d4-6f48-4df8-a3d8-2b0e442a163a@xxxxxxxxxxxxxxxxxxx (which
caused a rust-next breakage while trying to find possible fix for this problem) was not
discovered immediately because syzbot was unable to test next-202604{03,06,07,08,09,10}
due to a different bug. This problem was introduced at the worst timing (i.e. unable to
test around the merge window), and maintainers are not responding.

To minimize period of being unable to follow daily next-YYYYMMDD, I was sometimes sending
linux-next only patches that disable specific module under CONFIG_DEBUG_AID_FOR_SYZBOT=y, for
we can't predict when a maintainer responds to a build failure or boot failure in linux-next.
But now that you want me to stop sending linux-next only patches that disable specific module
under CONFIG_DEBUG_AID_FOR_SYZBOT=y, my question is what we can do to mitigate this "being
unable to follow daily next-YYYYMMDD" problem.