Re: Policy regarding linux-next only changes

On 2026/07/25 2:49, Miguel Ojeda wrote:
> On Fri, Jul 24, 2026 at 4:35 PM Tetsuo Handa
> <[email protected]> wrote:
>>
>> Those who hate my attempts (i.e. sending patches to linux-next without
>> being reviewed/acked by maintainers) are expecting that any patch is
>> reviewed/acked by maintainers. But some maintainers are considering bugs
> 
> It is not "hate", it is just the linux-next rules:
> 
>     "
>       * submitted under GPL v2 (or later) and include the Contributor's
>          Signed-off-by,
>       * posted to the relevant mailing list,
>       * reviewed by you (or another maintainer of your subsystem tree),
>       * successfully unit tested, and
>       * destined for the current or next Linux merge window.
>     "
> 
> That is why nobody is expecting random patches to appear there --
> because every maintainer receives those rules when they add their tree
> to linux-next.

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.

e.g. https://lkml.kernel.org/r/[email protected]
     (and I was using
      https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit?h=next-20260702&id=110ef9f94f84d425ab55d09b2d70ed12ceffdf08
      in order to help syzbot continue testing)

e.g. https://lkml.kernel.org/r/[email protected]
     (and I was using a linux-next only patch which disables this module for syzbot kernels
      (link to this patch already gone because this patch was more than 3 months ago)
      in order to help syzbot continue testing)

Also, WARN*() is abused just like printk() for catching oversights rather than
introducing grace period for confirmation, which is also preventing continuous testing
by syzbot. Sadly, developers/maintainers do not think that WARN*() is effectively panic()
for continuous testing systems. Unless developers/maintainers can apply all necessary
fixes within few days, WARN*() should not be used.

e.g. https://lkml.kernel.org/r/[email protected]
     (and I was not able to use a linux-next only patch because WQ is a core component
     which cannot be disabled for syzbot kernels)

The latest one seems to be https://lore.kernel.org/all/al1pElMQZsDfpAYI@michalis-linux/T/
     (but I am not able to use a linux-next only patch which disables this module
      for syzbot kernels in order to help syzbot continue testing, for I currently
      have no route to help syzbot continue testing)

> 
> And those rules make sense -- adding patches that are not ready or
> unexpected can confuse others, break the build, add conflicts or,
> worse of all, silently invalidate testing of normal patches going to
> Linus.

I am OK to post my debug patches to the relevant mailing list. But without
responses from developers / maintainers, my debug patches won't be able to
find a route to linux-next, which in turn prevents us from debugging.