Re: Policy regarding linux-next only changes

[Mark Brown]

On Sat, Jul 04, 2026 at 02:06:43PM +0200, Miguel Ojeda wrote:
> On Sat, Jul 4, 2026 at 12:15 PM Tetsuo Handa

> For the latter, it simply says that sometimes debugging patches have
> been added in the past to linux-next. It doesn't say it was done
> unilaterally. (And even if it did, it is just a third-party document).

...

> I understand it may be nice to use such resources, but the solution is
> to talk to both sides, as you do in that thread. From what I see, they
> even offered to add a mailing list for those patches:

Right, this seems to be something where people need to talk more.  It
does seem like there's real communication problems that need to be
addressed, it looks like some progress is being made thanks to this
thread.

Just dropping patches into -next that people are unaware of is going to
cause issues sooner or later.  Either there'll be some direct collision
with other work or (probably worse) they'll cause someone to think that
something is working better than it actually is since people testing
-next are testing with some extra stuff that the maintainers weren't
aware of.  It might be that the most sensible thing is to have some
extra patches in there for a period, it's an expected part of the flow
that things might get backed out after all, but we want to avoid
surprises.

> > I'm fine with announcing to ML that I am about to make debug/temporary changes.
> > But we might want a prefix for debug/temporary patches that are not intended for upstream?
> > Also, we might want a kernel config option (e.g. CONFIG_DEBUG_AID_FOR_SYZBOT) for
> > minimizing users affected?

TBH I think a prefix is probably not needed since there should be a bit
more communciation about what's going on than just posting the patch -
some discussion about how to debug whatever's going on for example.

Attachment: signature.asc
Description: PGP signature