linux-kernel - Re: [PATCH 0/4] Add agent coding assistant configuration to Linux kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aIpLB5oMc1tSq1SP@gallifrey>
Date: Wed, 30 Jul 2025 16:40:39 +0000
From: "Dr. David Alan Gilbert" <linux@...blig.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, Greg KH <greg@...ah.com>,
	Sasha Levin <sashal@...nel.org>, corbet@....net,
	linux-doc@...r.kernel.org, workflows@...r.kernel.org,
	josh@...htriplett.org, kees@...nel.org,
	konstantin@...uxfoundation.org, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 0/4] Add agent coding assistant configuration to Linux
 kernel

* Steven Rostedt (rostedt@...dmis.org) wrote:
> On Wed, 30 Jul 2025 16:34:28 +0100
> Lorenzo Stoakes <lorenzo.stoakes@...cle.com> wrote:
> 
> > > Which looked like someone else (now Cc'd on this thread) took it public,

(I didn't know of the tab discussion)

> > > and I wanted to see where that ended. I didn't want to start another
> > > discussion when there's already two in progress.  
> > 
> > OK, but having a document like this is not in my view optional - we must
> > have a clear, stated policy and one which ideally makes plain that it's
> > opt-in and maintainers may choose not to take these patches.
> 
> That sounds pretty much exactly as what I was stating in our meeting. That
> is, it is OK to submit a patch written with AI but you must disclose it. It
> is also the right of the Maintainer to refuse to take any patch that was
> written in AI. They may feel that they want someone who fully understands
> what that patch does, and AI can cloud the knowledge of that patch from the
> author.
> 
> I guess a statement in submitting-patches.rst would suffice, or should it
> be a separate standalone document?

If it's separate I think it needs to have a link from submitting-patches.rst
to get people to read it.

To summarise some other things that came up between the threads:
  a) I think there should be a standard syntax for stating it is
     AI written; I'd suggested using a new tag, but others were
     arguing on the side of reusing existing tags, which seems OK
     if it is done in a standard way and doesn't confuse existing tools.

  b) There's a whole spectrum of:
      i) AI wrote the whole patch based on a vague requirement
     ii) AI is in the editor and tab completes stuff
    iii) AI suggests fixes/changes
    which do you care about?

  c) But then once you get stuff suggesting fixes/changes people were
    wondering if you should specify other non-AI tools as well.
    That might help reviewers who get bombed by a million patches
    from some conventional tool.

  d) Either way there needs to be emphasis that the 'Signed-off-by'
    is a human declaring it's all legal and checked.

Dave

> -- Steve
> 
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/