On Wed, 30 Jul 2025 13:46:47 -0400 Sasha Levin <sashal@xxxxxxxxxx> 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 maintainer may not want to even bother with AI generated code can > >perhaps give the maintainer something to point to if push comes to shove. > > I don't think that those are technical aspects. I didn't either, but I was just saying one could possibly argue that they are. But that also states why it should be called out explicitly. As refusing AI patches may not be a technical issue where all other refusals should be. > >I wouldn't think so. This is about submitting patches and a statement there > >may be easier found by those about to submit an AI patch. Just because they > >are using AI doesn't mean they'll think it's an academic research. > > Not in the sense that AI is research, but more that this is code coming > from someone who is unable to reliably verify the patch that is being > sent in. The issue I have is that the person sending in the patch may not know that they don't understand the patch. We've had those in the past. I could imagine AI creating more of these kinds of submissions. > > The source can be academic research, AI, or whatever else comes along. > > It'll just be nice to have a unified set of rules around it. Otherwise > the amount of combinations will explode (in which category do we put in > academic researchers sending in AI generated code?). Research folks know they are doing research. Those using AI may likely will not, even if they are. Hence why I would like this outside of the academic research document. > > >> 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 patches, please have a reviewed-by from a > >> trusted developer before sending your patch". > >> > >> 3. No tool-generated patches without prior maintainer approval. > > > >Perhaps. Of course there's the Coccinelle scripts that fix a bunch of code > >around the kernel that will like be ignored in this. But this may still be > >a good start. > > It'll be hard to draw a line here, so I suggest we don't try. Agreed. But perhaps we could have a note that some subsystems expect all submissions done by a human. Although treewide patches that change interfaces that are fixed up by coccinelle may not have a choice. > > Are AI generated .cocci semantic patches that are then transformed into > C patches and sent in by a human ok? > Up to the maintainer. -- Steve