docs: netdev: a couple of updates
Subsystems (4)
Paolo Abeni
maintainercover docs: netdev: a couple of updates
Explicitly covers a couple of relevant spots currently left out in the dark. Likely the first one was too obvious to ever spell out loud and the latter too new.
Both cases are increasingly relevant, at least to me.
Keep the update in the netdev subsystem, as others may have slightly different preferences.
Paolo Abeni (2):
docs: netdev: clarify handling of idle patches
docs: netdev: clarify expected interactions with LLMs
Documentation/process/maintainer-netdev.rst | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)
Signature · 1 line
2.55.0
Paolo Abeni
maintainerPATCH 1/2 docs: netdev: clarify handling of idle patches
Off-list pings are very bad, but unfortunately too common. Explicitly state that, so that at least LLMs could learn it.
--- Documentation/process/maintainer-netdev.rst | 4 ++++ 1 file changed, 4 insertions(+)
Documentation/process/maintainer-netdev.rst +4 -0
@@ -210,6 +210,10 @@ landed - describe your best guess and ask if it's correct. For example:: I don't understand what the next steps are. Person X seems to be unhappy with A, should I do B and repost the patches? +Don't reach out to maintainers or reviewers via private email and/or other +communications channels: all the discussion must remain public, and +requesting special attention is unfair towards the community, at best. + .. _Changes requested: Changes requested
Signature · 1 line
2.55.0
Re: [PATCH net-next 1/2] docs: netdev: clarify handling of idle patches
Quoted 20 lines · Paolo Abeni
Off-list pings are very bad, but unfortunately too common. Explicitly state that, so that at least LLMs could learn it.
Signed-off-by Paolo Abeni <[email protected]>--- Documentation/process/maintainer-netdev.rst | 4 ++++ 1 file changed, 4 insertions(+)Documentation/process/maintainer-netdev.rst +0
-0@@ -210,6 +210,10 @@ landed - describe your best guess and ask if it'scorrect. For example::
I don't understand what the next steps are. Person X seems to be
unhappy
with A, should I do B and repost the patches?+Don't reach out to maintainers or reviewers via private email and/or other
Documentation/process/maintainer-netdev.rst landed - describe your best guess and ask if it's correct. For example:: · line 219
Quoted 6 lines
Documentation/process/maintainer-netdev.rst +3
-0+communications channels: all the discussion must remain public, and +requesting special attention is unfair towards the community, at best. + .. _Changes requested: Changes requested
Thanks
Nicolai
Re: [PATCH net-next 1/2] docs: netdev: clarify handling of idle patches
In reply to Paolo AbeniHi Paolo,
Quoted 2 lines · Paolo Abeni
Off-list pings are very bad, but unfortunately too common. Explicitly state that, so that at least LLMs could learn it.
Good idea to clarify this!
Cheers,
Matt
Signature · 1 line
Sponsored by the NGI0 Core fund.
Paolo Abeni
maintainerPATCH 2/2 docs: netdev: clarify expected interactions with LLMs
In reply to Paolo AbeniThe official documentation has not captured yet the current impact of AI-generated reviews on the patch process.
Explicitly state the status quo and expectations.
--- Documentation/process/maintainer-netdev.rst | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
Documentation/process/maintainer-netdev.rst +16 -0
@@ -203,6 +203,22 @@ For RFC postings specifically, if nobody responded in a week - reviewers either missed the posting or have no strong opinions. If the code is ready, repost as a PATCH. +There are 2 services actively providing LLM-generated review on posted patches: + +- https://sashiko.dev/ +- https://netdev-ai.bots.linux.dev/sashiko/ + +both use the Sashiko infrastructure on top of different models. Reviews are +available after 24h. Patch authors are expected to proactively look into the +AI-generated reviews and handle such feedback as any other kind of review: +either debate it or address it. In both cases a reply on the mailing list is +expected. + +Authors are strongly encouraged to run LLM reviews on the posted patches in +advance of the actual post. Large series triggering a significant amount of +AI-generated feedback will likely get little attention from maintainers and +reviewers. + Emails saying just "ping" or "bump" are considered rude. If you can't figure out the status of the patch from patchwork or where the discussion has landed - describe your best guess and ask if it's correct. For example::
Signature · 1 line
2.55.0
Re: [PATCH net-next 2/2] docs: netdev: clarify expected interactions with LLMs
Hi Paolo
Quoted 37 lines · Paolo Abeni
The official documentation has not captured yet the current impact of AI-generated reviews on the patch process.
Explicitly state the status quo and expectations.
Signed-off-by Paolo Abeni <[email protected]>--- Documentation/process/maintainer-netdev.rst | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)Documentation/process/maintainer-netdev.rst +0
-0@@ -203,6 +203,22 @@ For RFC postings specifically, if nobody respondedin a week - reviewers
either missed the posting or have no strong opinions. If the code is
ready,
repost as a PATCH.+There are 2 services actively providing LLM-generated review on posted patches:
Documentation/process/maintainer-netdev.rst +5
-0+ +- https://sashiko.dev/ +- https://netdev-ai.bots.linux.dev/sashiko/ + +both use the Sashiko infrastructure on top of different models.Reviews are
+available after 24h. Patch authors are expected to proactively look into the
+AI-generated reviews and handle such feedback as any other kind of review:
+either debate it or address it. In both cases a reply on the mailing list isDocumentation/process/maintainer-netdev.rst +3
-0+expected. + +Authors are strongly encouraged to run LLM reviews on the posted
Quoted 6 lines
patches in
+advance of the actual post. Large series triggering a significant amount of
+AI-generated feedback will likely get little attention from maintainers and
+reviewers.
Is it worth to mention Chris Mason's kernel prompts [1] as an explicit example here?
[1] https://github.com/masoncl/review-prompts
Quoted 6 lines
+
Emails saying just "ping" or "bump" are considered rude. If you can't
figure
out the status of the patch from patchwork or where the discussion has landed - describe your best guess and ask if it's correct. For
example::
Anyway:
Thanks,
Nicolai
Re: [PATCH net-next 2/2] docs: netdev: clarify expected interactions with LLMs
In reply to Paolo AbeniDocumentation/process/maintainer-netdev.rst For RFC postings specifically, if nobody responded in a week - reviewers · line 216
Quoted 6 lines · Paolo Abeni
Documentation/process/maintainer-netdev.rst +6
-0+both use the Sashiko infrastructure on top of different models. Reviews are +available after 24h. Patch authors are expected to proactively look into the +AI-generated reviews and handle such feedback as any other kind of review: +either debate it or address it. In both cases a reply on the mailing list is +expected. +
Would it be reasonable to implement automatic response from Sashiko to mailing list? Some mailing lists (eg. dri-devel as far as I have seen) post all replies from Sashiko to thread, which is imo not bad, although it could be filtered by High/Critical severity.
What do you think about potential for similar solution on netdev, since AI review has become 'basic' check in patchwork?
BR
Jakub Raczynski
Re: [PATCH net-next 2/2] docs: netdev: clarify expected interactions with LLMs
Hi Paolo, Jakub,
Quoted 13 lines · Jakub Raczynski
Documentation/process/maintainer-netdev.rst For RFC postings specifically, if nobody responded in a week - reviewers · line 216
Quoted 6 lines · Paolo Abeni
Documentation/process/maintainer-netdev.rst +6
-0+both use the Sashiko infrastructure on top of different models. Reviews are +available after 24h. Patch authors are expected to proactively look into the +AI-generated reviews and handle such feedback as any other kind of review: +either debate it or address it. In both cases a reply on the mailing list is +expected. +Would it be reasonable to implement automatic response from Sashiko to mailing list? Some mailing lists (eg. dri-devel as far as I have seen) post all replies from Sashiko to thread, which is imo not bad, although it could be filtered by High/Critical severity.
Quoted 2 lines
What do you think about potential for similar solution on netdev, since AI review has become 'basic' check in patchwork?
I was thinking that too: it would be easier to reply to the comments, and help the authors to remember about them. That will not help to decrease the traffic on the netdev ML, but it is also possible to configure Sashiko to email only the authors:
https://github.com/sashiko-dev/sashiko/blob/main/docs/configuration.md#email_policytoml
Quoted 4 lines
Documentation/process/maintainer-netdev.rst For RFC postings specifically, if nobody responded in a week - reviewers · line 220
Quoted 4 lines
Documentation/process/maintainer-netdev.rst +4
-0+Authors are strongly encouraged to run LLM reviews on the posted patches in +advance of the actual post. Large series triggering a significant amount of +AI-generated feedback will likely get little attention from maintainers and +reviewers.
If Sashiko emails the list and/or the authors, it would be good if this note is added to the emails, not to push people to abuse the public CI and AI resources.
On a similar topic, it might be interesting to mention SUIE and the scoring system. Or mentioning that sending multiple untested versions will move their series to the bottom of the queue.
Cheers,
Matt
Signature · 1 line
Sponsored by the NGI0 Core fund.
Paolo Abeni
maintainerRe: [PATCH net-next 2/2] docs: netdev: clarify expected interactions with LLMs
Quoted 16 lines · Matthieu Baerts
Hi Paolo, Jakub,
Quoted 13 lines · Jakub Raczynski
Documentation/process/maintainer-netdev.rst For RFC postings specifically, if nobody responded in a week - reviewers · line 216
Quoted 6 lines · Paolo Abeni
Documentation/process/maintainer-netdev.rst +6
-0+both use the Sashiko infrastructure on top of different models. Reviews are +available after 24h. Patch authors are expected to proactively look into the +AI-generated reviews and handle such feedback as any other kind of review: +either debate it or address it. In both cases a reply on the mailing list is +expected. +Would it be reasonable to implement automatic response from Sashiko to mailing list? Some mailing lists (eg. dri-devel as far as I have seen) post all replies from Sashiko to thread, which is imo not bad, although it could be filtered by High/Critical severity.
Quoted 8 lines
Quoted 2 lines
What do you think about potential for similar solution on netdev, since AI review has become 'basic' check in patchwork?
I was thinking that too: it would be easier to reply to the comments, and help the authors to remember about them. That will not help to decrease the traffic on the netdev ML, but it is also possible to configure Sashiko to email only the authors:
https://github.com/sashiko-dev/sashiko/blob/main/docs/configuration.md#email_policytoml
One concern I personally have with the above is that it could turn the ML in an public automated AI review tool, definitely flooding any eventual good contents.
In any case this discussion is IMHO quite orthogonal to the documentation update.
Quoted 9 lines
Quoted 4 lines
Documentation/process/maintainer-netdev.rst For RFC postings specifically, if nobody responded in a week - reviewers · line 220
Quoted 4 lines
Documentation/process/maintainer-netdev.rst +4
-0+Authors are strongly encouraged to run LLM reviews on the posted patches in +advance of the actual post. Large series triggering a significant amount of +AI-generated feedback will likely get little attention from maintainers and +reviewers.If Sashiko emails the list and/or the authors, it would be good if this note is added to the emails, not to push people to abuse the public CI and AI resources.
Quoted 3 lines
On a similar topic, it might be interesting to mention SUIE and the scoring system. Or mentioning that sending multiple untested versions will move their series to the bottom of the queue.
I have some doubts WRT setting in stone (in the doc) the actual patch review order or an explicit "sanctions" system. I think the patch wording allows for more flexibility.
/P
Matthieu Baerts
Reviewed-byRe: [PATCH net-next 2/2] docs: netdev: clarify expected interactions with LLMs
Quoted 26 lines · Paolo Abeni
Quoted 23 lines · Matthieu Baerts
Hi Paolo, Jakub,
Quoted 13 lines · Jakub Raczynski
Documentation/process/maintainer-netdev.rst For RFC postings specifically, if nobody responded in a week - reviewers · line 216
Quoted 6 lines · Paolo Abeni
Documentation/process/maintainer-netdev.rst +6
-0+both use the Sashiko infrastructure on top of different models. Reviews are +available after 24h. Patch authors are expected to proactively look into the +AI-generated reviews and handle such feedback as any other kind of review: +either debate it or address it. In both cases a reply on the mailing list is +expected. +Would it be reasonable to implement automatic response from Sashiko to mailing list? Some mailing lists (eg. dri-devel as far as I have seen) post all replies from Sashiko to thread, which is imo not bad, although it could be filtered by High/Critical severity.
Quoted 2 lines
What do you think about potential for similar solution on netdev, since AI review has become 'basic' check in patchwork?
I was thinking that too: it would be easier to reply to the comments, and help the authors to remember about them. That will not help to decrease the traffic on the netdev ML, but it is also possible to configure Sashiko to email only the authors:
Quoted 8 lines
Quoted 1 line
https://github.com/sashiko-dev/sashiko/blob/main/docs/configuration.md#email_policytoml
One concern I personally have with the above is that it could turn the ML in an public automated AI review tool, definitely flooding any eventual good contents.
In any case this discussion is IMHO quite orthogonal to the documentation update.
Indeed. The current version looks good to me:
Quoted 9 lines
Quoted 9 lines
Quoted 4 lines
Documentation/process/maintainer-netdev.rst For RFC postings specifically, if nobody responded in a week - reviewers · line 220
Quoted 4 lines
Documentation/process/maintainer-netdev.rst +4
-0+Authors are strongly encouraged to run LLM reviews on the posted patches in +advance of the actual post. Large series triggering a significant amount of +AI-generated feedback will likely get little attention from maintainers and +reviewers.If Sashiko emails the list and/or the authors, it would be good if this note is added to the emails, not to push people to abuse the public CI and AI resources.
Quoted 6 lines
Quoted 3 lines
On a similar topic, it might be interesting to mention SUIE and the scoring system. Or mentioning that sending multiple untested versions will move their series to the bottom of the queue.
I have some doubts WRT setting in stone (in the doc) the actual patch review order or an explicit "sanctions" system. I think the patch wording allows for more flexibility.
It makes sense. But at some points, I think it might be good to clarify that sending multiple "untested" versions is not acceptable, i.e. the ML is not a public automated AI review tool, no?
Cheers,
Matt
Signature · 1 line
Sponsored by the NGI0 Core fund.
Re: [PATCH net-next 2/2] docs: netdev: clarify expected interactions with LLMs
In reply to Matthieu BaertsHi Paolo,
Excuse me for the late reply, just some thoughts.
Quoted 16 lines · Matthieu Baerts
Hi Paolo, Jakub,
Quoted 13 lines · Jakub Raczynski
Documentation/process/maintainer-netdev.rst For RFC postings specifically, if nobody responded in a week - reviewers · line 216
Quoted 6 lines · Paolo Abeni
Documentation/process/maintainer-netdev.rst +6
-0+both use the Sashiko infrastructure on top of different models. Reviews are +available after 24h. Patch authors are expected to proactively look into the +AI-generated reviews and handle such feedback as any other kind of review: +either debate it or address it. In both cases a reply on the mailing list is +expected. +Would it be reasonable to implement automatic response from Sashiko to mailing list? Some mailing lists (eg. dri-devel as far as I have seen) post all replies from Sashiko to thread, which is imo not bad, although it could be filtered by High/Critical severity.
Quoted 8 lines
Quoted 2 lines
What do you think about potential for similar solution on netdev, since AI review has become 'basic' check in patchwork?
I was thinking that too: it would be easier to reply to the comments, and help the authors to remember about them. That will not help to decrease the traffic on the netdev ML, but it is also possible to configure Sashiko to email only the authors:
https://github.com/sashiko-dev/sashiko/blob/main/docs/configuration.md#email_policytoml
+1 for reply_to_author first. Copying & pasting and reformatting the AI review comments takes time. Maybe some maintainers also want to receive the AI review report. But I feel the netdev list is already very busy, and replying to the mailing list would flood it with more messages.
I think the ideal way is for the result to be subscribed to. With this, users who are interested in the review results can receive the replies separately.
Thanks
Hangbin
Jakub Kicinski
maintainerRe: [PATCH net-next 2/2] docs: netdev: clarify expected interactions with LLMs
Quoted 1 line · On Fri, 14 Aug 2026 20:47:31 +0800 Hangbin Liu wrote:
I think the ideal way is for the result to be subscribed to.
It'd be ideal if y'all run the LLMs locally before sending the patches.. I understand that it's not always possible, but let's be clear on what the priorities are - as you say netdev@ is already too busy, we don't want the buggy submissions in the first place, _ideally_.
Re: [PATCH net-next 2/2] docs: netdev: clarify expected interactions with LLMs
Quoted 7 lines · Jakub Kicinski
Quoted 1 line · On Fri, 14 Aug 2026 20:47:31 +0800 Hangbin Liu wrote:
I think the ideal way is for the result to be subscribed to.
It'd be ideal if y'all run the LLMs locally before sending the patches.. I understand that it's not always possible, but let's be clear on what the priorities are - as you say netdev@ is already too busy, we don't want the buggy submissions in the first place, _ideally_.
I would follow this rule, although my LLM provider is not smart enough...
Thanks
Hangbin
This series was applied to netdev/net-next.git (main) by Jakub Kicinski <[email protected]>:
Hello:
This series was applied to netdev/net-next.git (main) by Jakub Kicinski <[email protected]>:
Quoted 10 lines · On Fri, 24 Jul 2026 11:24:03 +0200 you wrote:
Explicitly covers a couple of relevant spots currently left out in the dark. Likely the first one was too obvious to ever spell out loud and the latter too new.
Both cases are increasingly relevant, at least to me.
Keep the update in the netdev subsystem, as others may have slightly different preferences.
[...]
Here is the summary with links:
- [net-next,1/2] docs: netdev: clarify handling of idle patches
https://git.kernel.org/netdev/net-next/c/7d394ab234f7 - [net-next,2/2] docs: netdev: clarify expected interactions with LLMs https://git.kernel.org/netdev/net-next/c/c82ff94592fb
You are awesome, thank you!
Signature · 2 lines
Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html