Re: Policy regarding linux-next only changes

[Mark Brown]

On Mon, Jul 27, 2026 at 10:19:26PM +0900, Tetsuo Handa wrote:
> 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

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

No, what I'm describing applies to everyone.  It's a bit more important
that if you're adding things not for your own tree that you don't mess
up, but I do actually occasionally find myself removing trees because of
disruption they are causing.

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

This really just looks like another case where you (or someone) need to
commuicate if something is urgent - I would have a hard time telling
from that thread that there's a particularly big problem, the only reply
indicating any kind of problem with the posted patch (from Joshua) was
then followed up saying to disrgard it and there's nothing at all at any
point in the thread or original report about the scope of the issue or
any practical impact it's having.  Frankly I'm not clear that Michail
(who posted the patch) is aware that there's any urgency here and isn't
just acting reasonably and promptly on what was in the report mail.

Even if someone were to click through the syzbot link the report is
flagged as low priority in the dashboard and the config is just a link
to a raw config so there's no indication if this is defconfig,
randconfig or whatever.  There's absolutely nothing in the sysbot
dashboard or list report that indicates to me that this has any kind of
impact beyond "a warning is displayed during boot".

If this were something super urgent I would expect to see people
following up saying clearly why that's the case, doing so repeatedly if
things take a while.  That simply isn't happening here, from what's
visible I really don't know how anyone is expected to infer that this
isn't just a fairly standard bugfix for a routine issue that was only
reported a week ago.  Perhaps this is all clear if you are familiar with
how exactly syzbot works but most people aren't.

Attachment: signature.asc
Description: PGP signature