On Sonntag, 27. Juli 2025 21:57:58 Mitteleuropäische Sommerzeit Sasha Levin
wrote:
> This patch series adds unified configuration and documentation for coding
> agents working with the Linux kernel codebase. As coding agents
> become increasingly common in software development, it's important to
>
On Tue, 5 Aug 2025 02:39:06 +0300
Laurent Pinchart wrote:
> > >
> > >"Be prepared to declare a confidence interval in every detail of a patch
> > >series, especially any AI generated pieces."
Honestly, I think we need to state that.
> >
> > Something along the lines of a Social Credit system
On Mon, Aug 04, 2025 at 07:30:41PM -0400, Sasha Levin wrote:
> On Mon, Aug 04, 2025 at 03:53:50PM -0700, dan.j.willi...@intel.com wrote:
> >Steven Rostedt wrote:
> >> On Tue, 5 Aug 2025 00:03:29 +0200 (CEST)
> >> Jiri Kosina wrote:
> >>
> >> > Al made a very important point somewhere earlier in th
On Mon, Aug 04, 2025 at 03:53:50PM -0700, dan.j.willi...@intel.com wrote:
Steven Rostedt wrote:
On Tue, 5 Aug 2025 00:03:29 +0200 (CEST)
Jiri Kosina wrote:
> Al made a very important point somewhere earlier in this thread.
>
> The most important (from the code quality POV) thing is -- is there
Steven Rostedt wrote:
> On Tue, 5 Aug 2025 00:03:29 +0200 (CEST)
> Jiri Kosina wrote:
>
> > Al made a very important point somewhere earlier in this thread.
> >
> > The most important (from the code quality POV) thing is -- is there a
> > person that understands the patch enough to be able to a
On Mon, 4 Aug 2025, Steven Rostedt wrote:
> I know we can't change the DCO, but could we add something about our policy
> is that if you submit code, you certify that you understand said code, even
> if (especially) it was produced by AI?
Yeah, I think that's *precisely* what's needed.
Legal stu
On Tue, 5 Aug 2025 00:03:29 +0200 (CEST)
Jiri Kosina wrote:
> Al made a very important point somewhere earlier in this thread.
>
> The most important (from the code quality POV) thing is -- is there a
> person that understands the patch enough to be able to answer questions
> (coming from some
On Mon, 4 Aug 2025, Sasha Levin wrote:
> > The above guidance is quite vague. How me as a maintainer should know
> > that whatever AI tool has been used is meeting those two conditions
>
> In exactly the same way you know that a human contributor didn't copy
> code with an incompatible license.
>
On Mon, Aug 04, 2025 at 11:23:21AM +0200, Michal Hocko wrote:
On Mon 28-07-25 09:05:37, Sasha Levin wrote:
On Mon, Jul 28, 2025 at 12:47:55PM +0200, David Hildenbrand wrote:
> We cannot keep complaining about maintainer overload and, at the same
> time, encourage people to bombard us with even m
On Wed, 30 Jul 2025, Lorenzo Stoakes wrote:
> > This way we can extend MAINTAINERS to indicate which subsystems are
> > more open to research work (drivers/staging/ comes to mind) vs ones that
> > aren't.
> >
> > Some sort of a "traffic light" system:
> >
> > 1. Green: the subsystem is happy to r
On Mon 04-08-25 11:23:22, Michal Hocko wrote:
> On Mon 28-07-25 09:05:37, Sasha Levin wrote:
> > On Mon, Jul 28, 2025 at 12:47:55PM +0200, David Hildenbrand wrote:
> > > We cannot keep complaining about maintainer overload and, at the same
> > > time, encourage people to bombard us with even more o
On Mon 28-07-25 09:05:37, Sasha Levin wrote:
> On Mon, Jul 28, 2025 at 12:47:55PM +0200, David Hildenbrand wrote:
> > We cannot keep complaining about maintainer overload and, at the same
> > time, encourage people to bombard us with even more of that stuff.
> >
> > Clearly flagging stuff as AI-ge
Em Wed, 30 Jul 2025 13:46:47 -0400
Sasha Levin escreveu:
> >> Some sort of a "traffic light" system:
> >>
> >> 1. Green: the subsystem is happy to receive patches from any source.
> >>
> >> 2. Yellow: "If you're unfamiliar with the subsystem and using any
> >> tooling to generate your patch
On Wed, Jul 30, 2025 at 03:10:33PM -0400, Theodore Ts'o wrote:
> On Wed, Jul 30, 2025 at 06:59:09PM +0100, Al Viro wrote:
> >
> > And I absolutely will refuse to take patches from somebody who would
> > consistently fail to explain why the patch is correct and needed. Sasha,
> > this is the eleph
On Wed, 30 Jul 2025 15:10:33 -0400
"Theodore Ts'o" wrote:
> Any tool can be a force multipler, either for good or for ill.
>
> For example, I suspect we have a much greater set of problems from
> $TOOL's other than Large Language Models. For example people who use
> "git grep strcpy" and send p
On Wed, 30 Jul 2025 13:46:47 -0400
Sasha Levin wrote:
> >My point here is that AI can now add questions that maintainers can't
> >answer. Is it really legal? Can the maintainer trust it? Yes, these too can
> >fall under the "technical reasons" but having a clear policy that states
> >that a maint
On Wed, Jul 30, 2025 at 07:04:13PM +0100, Lorenzo Stoakes wrote:
> On Wed, Jul 30, 2025 at 01:32:20PM -0400, Steven Rostedt wrote:
> > If the maintainer starts getting too many submissions, then they can update
> > the MAINTAINERS file to say "stop all AI patches to me!". Just like we have
> > an
On Wed, Jul 30, 2025 at 06:59:09PM +0100, Al Viro wrote:
>
> And I absolutely will refuse to take patches from somebody who would
> consistently fail to explain why the patch is correct and needed. Sasha,
> this is the elephant in the room: we *ALREADY* get "contributions" that
> very clearly ste
On Wed, Jul 30, 2025 at 07:24:13PM +0100, Lorenzo Stoakes wrote:
On Wed, Jul 30, 2025 at 02:10:26PM -0400, Sasha Levin wrote:
On Wed, Jul 30, 2025 at 06:59:09PM +0100, Al Viro wrote:
> On Wed, Jul 30, 2025 at 01:46:47PM -0400, Sasha Levin wrote:
>
> > Similarily the argument around not trusting
On Wed, Jul 30, 2025 at 02:10:26PM -0400, Sasha Levin wrote:
> On Wed, Jul 30, 2025 at 06:59:09PM +0100, Al Viro wrote:
> > On Wed, Jul 30, 2025 at 01:46:47PM -0400, Sasha Levin wrote:
> >
> > > Similarily the argument around not trusting the code is equivalent to
> > > not trusting the person who
On Wed, Jul 30, 2025 at 02:03:38PM -0400, Sasha Levin wrote:
> On Wed, Jul 30, 2025 at 01:32:20PM -0400, Steven Rostedt wrote:
> > On Wed, 30 Jul 2025 18:23:14 +0100
> > Lorenzo Stoakes wrote:
> > > You might suggest presuming a policy for maintainers is inappropriate, but
> > > you are doing so w
On Wed, Jul 30, 2025 at 06:59:09PM +0100, Al Viro wrote:
On Wed, Jul 30, 2025 at 01:46:47PM -0400, Sasha Levin wrote:
Similarily the argument around not trusting the code is equivalent to
not trusting the person who sent the code in. AI doesn't send patches on
it's own - humans do. This is basi
On Wed, Jul 30, 2025 at 01:32:20PM -0400, Steven Rostedt wrote:
On Wed, 30 Jul 2025 18:23:14 +0100
Lorenzo Stoakes wrote:
You might suggest presuming a policy for maintainers is inappropriate, but
you are doing so wrt the LF policy on the assumption everybody is aware and
agrees with it.
No,
On Wed, Jul 30, 2025 at 01:32:20PM -0400, Steven Rostedt wrote:
>
> >
> > Assuming every maintainer accepts AI patches unless explicitly opted out is
> > very clearly not something that will be acceptable to people.
>
> You can opt out when you receive your first AI patch ;-)
Yeah, there's just no
On Wed, Jul 30, 2025 at 01:46:47PM -0400, Sasha Levin wrote:
> Similarily the argument around not trusting the code is equivalent to
> not trusting the person who sent the code in. AI doesn't send patches on
> it's own - humans do. This is basically saying "I didn't even look at
> your patch becau
On Wed, Jul 30, 2025 at 04:40:39PM +, Dr. David Alan Gilbert wrote:
> 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?
Th
On Wed, Jul 30, 2025 at 01:05:31PM -0400, Steven Rostedt wrote:
On Wed, 30 Jul 2025 12:36:25 -0400
Sasha Levin wrote:
>
>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
* Steven Rostedt (rost...@goodmis.org) wrote:
> On Wed, 30 Jul 2025 16:40:39 +
> "Dr. David Alan Gilbert" wrote:
>
> > * Steven Rostedt (rost...@goodmis.org) wrote:
> > > On Wed, 30 Jul 2025 16:34:28 +0100
> > > Lorenzo Stoakes wrote:
> > >
> > > > > Which looked like someone else (now Cc
On Wed, Jul 30, 2025 at 05:59:25PM +0100, Lorenzo Stoakes wrote:
> On Wed, Jul 30, 2025 at 12:36:25PM -0400, Sasha Levin wrote:
> > Some sort of a "traffic light" system:
> >
> > 1. Green: the subsystem is happy to receive patches from any source.
> >
> > 2. Yellow: "If you're unfamiliar with the
On Wed, Jul 30, 2025 at 05:59:25PM +0100, Lorenzo Stoakes wrote:
> On Wed, Jul 30, 2025 at 12:36:25PM -0400, Sasha Levin wrote:
> > Some sort of a "traffic light" system:
> > 1. Green: the subsystem is happy to receive patches from any source.
> > 2. Yellow: "If you're unfamiliar with the subs
On Wed, Jul 30, 2025 at 01:20:54PM -0400, Steven Rostedt wrote:
> On Wed, 30 Jul 2025 18:10:51 +0100
> Lorenzo Stoakes wrote:
>
>
> > > > I guess a statement in submitting-patches.rst would suffice, or should
> > > > it
> > > > be a separate standalone document?
> > >
> > > If it's separate I thi
On Wed, 30 Jul 2025 18:23:14 +0100
Lorenzo Stoakes wrote:
> > I don't think we should (or can) set a policy here for other
> > maintainers. Right now we allow tool-assisted contributions - flipping
> > this would mean we need to get an ack from at least a majority of the
> > MAINTAINERS folks.
On Wed, 30 Jul 2025 13:12:54 -0400
Sasha Levin wrote:
> >>
> >> Some sort of a "traffic light" system:
> >>
> >> 1. Green: the subsystem is happy to receive patches from any source.
> >>
> >> 2. Yellow: "If you're unfamiliar with the subsystem and using any
> >> tooling to generate your patche
On Wed, Jul 30, 2025 at 01:12:54PM -0400, Sasha Levin wrote:
> On Wed, Jul 30, 2025 at 05:59:25PM +0100, Lorenzo Stoakes wrote:
> > On Wed, Jul 30, 2025 at 12:36:25PM -0400, Sasha Levin wrote:
> > > On Wed, Jul 30, 2025 at 12:18:29PM -0400, Steven Rostedt wrote:
> > > > On Wed, 30 Jul 2025 16:34:28
On Wed, 30 Jul 2025 18:10:51 +0100
Lorenzo Stoakes wrote:
> > > 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.
On Wed, Jul 30, 2025 at 05:59:25PM +0100, Lorenzo Stoakes wrote:
On Wed, Jul 30, 2025 at 12:36:25PM -0400, Sasha Levin wrote:
On Wed, Jul 30, 2025 at 12:18:29PM -0400, Steven Rostedt wrote:
> On Wed, 30 Jul 2025 16:34:28 +0100
> Lorenzo Stoakes wrote:
>
> > > Which looked like someone else (now
On Wed, 30 Jul 2025 16:40:39 +
"Dr. David Alan Gilbert" wrote:
> * Steven Rostedt (rost...@goodmis.org) wrote:
> > On Wed, 30 Jul 2025 16:34:28 +0100
> > Lorenzo Stoakes wrote:
> >
> > > > Which looked like someone else (now Cc'd on this thread) took it
> > > > public,
>
> (I didn't k
On Wed, Jul 30, 2025 at 04:40:39PM +, Dr. David Alan Gilbert wrote:
> * Steven Rostedt (rost...@goodmis.org) wrote:
> > On Wed, 30 Jul 2025 16:34:28 +0100
> > Lorenzo Stoakes wrote:
> >
> > > > Which looked like someone else (now Cc'd on this thread) took it public,
>
> (I didn't know of the t
On Wed, 30 Jul 2025 12:36:25 -0400
Sasha Levin wrote:
> >
> >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
> >wri
On Wed, Jul 30, 2025 at 12:36:25PM -0400, Sasha Levin wrote:
> On Wed, Jul 30, 2025 at 12:18:29PM -0400, Steven Rostedt wrote:
> > On Wed, 30 Jul 2025 16:34:28 +0100
> > Lorenzo Stoakes wrote:
> >
> > > > Which looked like someone else (now Cc'd on this thread) took it public,
> > > > and I wanted
On Wed, Jul 30, 2025 at 12:18:29PM -0400, Steven Rostedt wrote:
> On Wed, 30 Jul 2025 16:34:28 +0100
> Lorenzo Stoakes wrote:
>
> > > Which looked like someone else (now Cc'd on this thread) took it public,
> > > and I wanted to see where that ended. I didn't want to start another
> > > discussion
* Steven Rostedt (rost...@goodmis.org) wrote:
> On Wed, 30 Jul 2025 16:34:28 +0100
> Lorenzo Stoakes 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 a
On Wed, Jul 30, 2025 at 12:18:29PM -0400, Steven Rostedt wrote:
On Wed, 30 Jul 2025 16:34:28 +0100
Lorenzo Stoakes wrote:
> Which looked like someone else (now Cc'd on this thread) took it public,
> and I wanted to see where that ended. I didn't want to start another
> discussion when there's
Em Wed, 30 Jul 2025 12:18:29 -0400
Steven Rostedt escreveu:
> On Wed, 30 Jul 2025 16:34:28 +0100
> Lorenzo Stoakes wrote:
>
> > > Which looked like someone else (now Cc'd on this thread) took it public,
> > > and I wanted to see where that ended. I didn't want to start another
> > > discussion
On Wed, 30 Jul 2025 16:34:28 +0100
Lorenzo Stoakes wrote:
> > Which looked like someone else (now Cc'd on this thread) took it public,
> > 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 lik
On Wed, Jul 30, 2025 at 11:27:53AM -0400, Steven Rostedt wrote:
> On Mon, 28 Jul 2025 11:52:47 +0100
> Lorenzo Stoakes wrote:
>
> > On Mon, Jul 28, 2025 at 12:35:02PM +0200, Greg KH wrote:
> > > > So to me:
> > > >
> > > > - We should establish an official kernel AI policy document.
> > >
> > > St
On Mon, 28 Jul 2025 11:52:47 +0100
Lorenzo Stoakes wrote:
> On Mon, Jul 28, 2025 at 12:35:02PM +0200, Greg KH wrote:
> > > So to me:
> > >
> > > - We should establish an official kernel AI policy document.
> >
> > Steven Rostedt is working on this right now, hopefully he has something
> > "soon
On Mon, Jul 28, 2025 at 09:23:19AM -0400, Sasha Levin wrote:
> On Mon, Jul 28, 2025 at 02:13:01PM +0100, Lorenzo Stoakes wrote:
> > On Mon, Jul 28, 2025 at 08:45:19AM -0400, Sasha Levin wrote:
> > > > So at all times I think ensuring the human element is aware that they
> > > > need
> > > > to do
On Mon, Jul 28, 2025 at 02:13:01PM +0100, Lorenzo Stoakes wrote:
On Mon, Jul 28, 2025 at 08:45:19AM -0400, Sasha Levin wrote:
> So at all times I think ensuring the human element is aware that they need
> to do some kind of checking/filtering is key.
>
> But that can be handled by a carefully wo
On Mon, Jul 28, 2025 at 08:45:19AM -0400, Sasha Levin wrote:
> On Mon, Jul 28, 2025 at 11:52:47AM +0100, Lorenzo Stoakes wrote:
> > One thing to note is that I struggled to get an LLM to read MAINTAINERS
> > properly recently (it assured me, with absolute confidence, that the SLAB
> > ALLOCATOR sec
On Mon, Jul 28, 2025 at 12:47:55PM +0200, David Hildenbrand wrote:
We cannot keep complaining about maintainer overload and, at the same
time, encourage people to bombard us with even more of that stuff.
Clearly flagging stuff as AI-generated can maybe help. But really,
what we need is a prope
On Mon, Jul 28, 2025 at 11:52:47AM +0100, Lorenzo Stoakes wrote:
One thing to note is that I struggled to get an LLM to read MAINTAINERS
properly recently (it assured me, with absolute confidence, that the SLAB
ALLOCATOR section was in fact 'SLAB ALLOCATORS' + provided me with
completely incorrec
On Mon, Jul 28, 2025 at 09:58:44AM +0200, Vlastimil Babka wrote:
On 7/27/25 21:57, Sasha Levin wrote:
This patch series adds unified configuration and documentation for coding
agents working with the Linux kernel codebase. As coding agents
become increasingly common in software development, it's
On Mon, Jul 28, 2025 at 12:35:02PM +0200, Greg KH wrote:
> On Mon, Jul 28, 2025 at 09:42:27AM +0100, Lorenzo Stoakes wrote:
> > +cc Linus
> >
> > On Sun, Jul 27, 2025 at 03:57:58PM -0400, Sasha Levin wrote:
> > > This patch series adds unified configuration and documentation for coding
> > > agent
On Mon, Jul 28, 2025 at 12:35:02PM +0200, Greg KH wrote:
> > So to me:
> >
> > - We should establish an official kernel AI policy document.
>
> Steven Rostedt is working on this right now, hopefully he has something
> "soon".
Great! Thanks for looking at that Steve.
I think a key element here has
On 28.07.25 12:37, Greg KH wrote:
On Mon, Jul 28, 2025 at 11:27:48AM +0200, David Hildenbrand wrote:
This must not be the new mechanism to DoS kernel maintainers with AI slop.
I will note that we are already getting this kind of "slop" today, with
the numbers going up on a weekly basis. Be lu
On Mon, Jul 28, 2025 at 11:27:48AM +0200, David Hildenbrand wrote:
> This must not be the new mechanism to DoS kernel maintainers with AI slop.
I will note that we are already getting this kind of "slop" today, with
the numbers going up on a weekly basis. Be lucky if you haven't seen it
in your s
On Mon, Jul 28, 2025 at 09:42:27AM +0100, Lorenzo Stoakes wrote:
> +cc Linus
>
> On Sun, Jul 27, 2025 at 03:57:58PM -0400, Sasha Levin wrote:
> > This patch series adds unified configuration and documentation for coding
> > agents working with the Linux kernel codebase. As coding agents
> > become
On 28.07.25 09:58, Vlastimil Babka wrote:
On 7/27/25 21:57, Sasha Levin wrote:
This patch series adds unified configuration and documentation for coding
agents working with the Linux kernel codebase. As coding agents
become increasingly common in software development, it's important to
establish
+cc Linus
On Sun, Jul 27, 2025 at 03:57:58PM -0400, Sasha Levin wrote:
> This patch series adds unified configuration and documentation for coding
> agents working with the Linux kernel codebase. As coding agents
> become increasingly common in software development, it's important to
> establish c
On 7/27/25 21:57, Sasha Levin wrote:
> This patch series adds unified configuration and documentation for coding
> agents working with the Linux kernel codebase. As coding agents
> become increasingly common in software development, it's important to
> establish clear guidelines for their use in ke
61 matches
Mail list logo
