From: Mark Brown <broonie@kernel.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Alexander Potapenko <glider@google.com>,
Boqun Feng <boqun@kernel.org>, Gary Guo <gary@garyguo.net>,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
Miguel Ojeda <ojeda@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
peterz@infradead.org, will@kernel.org, longman@redhat.com,
mingo@kernel.org, gregkh@linuxfoundation.org
Subject: Re: Policy regarding linux-next only changes
Date: Sun, 5 Jul 2026 13:06:40 +0100 [thread overview]
Message-ID: <akpI0IIqgXCXmQhQ@sirena.co.uk> (raw)
In-Reply-To: <CANiq72=hLXip=gQS1tnLQxe6Kpwq03Bd8F1z_xLrdoCtvSAkfg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1860 bytes --]
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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2026-07-05 12:06 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-02 11:49 Policy regarding linux-next only changes Gary Guo
2026-07-02 12:49 ` Tetsuo Handa
2026-07-02 13:37 ` Miguel Ojeda
2026-07-02 14:11 ` Boqun Feng
2026-07-04 10:14 ` Tetsuo Handa
2026-07-04 12:06 ` Miguel Ojeda
2026-07-04 13:22 ` Theodore Tso
2026-07-05 11:36 ` Tetsuo Handa
2026-07-05 12:02 ` Miguel Ojeda
2026-07-05 12:06 ` Miguel Ojeda
2026-07-05 12:20 ` Mark Brown
2026-07-05 12:06 ` Mark Brown [this message]
2026-07-05 14:16 ` Tetsuo Handa
2026-07-06 17:23 ` Mark Brown
2026-07-05 9:05 ` [PATCH] lockdep: Enable the printing of held locks of running non-current tasks (was: Policy regarding linux-next only changes) Ingo Molnar
2026-07-05 11:05 ` [PATCH] lockdep: Enable the printing of held locks of running non-current tasks Tetsuo Handa
2026-07-07 7:20 ` [PATCH -v2] lockdep: Enable the printing of held locks of remote running tasks and print task CPU Ingo Molnar
2026-07-05 14:59 ` Policy regarding linux-next only changes Boqun Feng
2026-07-02 13:22 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=akpI0IIqgXCXmQhQ@sirena.co.uk \
--to=broonie@kernel.org \
--cc=boqun@kernel.org \
--cc=gary@garyguo.net \
--cc=glider@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=longman@redhat.com \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=mingo@kernel.org \
--cc=ojeda@kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox