On Tue, Jan 13, 2026 at 08:30:51AM +0300, Dan Carpenter wrote: > On Mon, Jan 12, 2026 at 04:06:12PM -0800, Dave Hansen wrote: > > +As with all contributions, individual maintainers have discretion to > > +choose how they handle the contribution. For example, they might: > > + > > + - Treat it just like any other contribution. > > + - Reject it outright. > > + - Treat the contribution specially like reviewing with extra scrutiny, > > + or at a lower priority than human-generated content. > > + - Suggest a better prompt instead of suggesting specific code changes. > > + - Ask for some other special steps, like asking the contributor to > > + elaborate on how the tool or model was trained. > > + - Ask the submitter to explain in more detail about the contribution > > + so that the maintainer can be assured that the submitter fully > > + understands how the code works. > > + > > +If tools permit you to generate a contribution automatically, expect > > +additional scrutiny in proportion to how much of it was generated. > > + > > +As with the output of any tooling, the result may be incorrect or > > +inappropriate. You are expected to understand and to be able to defend > > +everything you submit. If you are unable to do so, then do not submit > > +the resulting changes. > > + > > +If you do so anyway, maintainers are entitled to reject your series > > +without detailed review. > > Argh... Flip. In context, that sounds even more sinister and > threatening than my over the top proposal. We have to "defend" > everything? "If you do so anyway" sounds like we're jumping to a > "per my last email" from the get go. What about:
I disagree entirely - you have to be able to understand what you submit and defend it in code review this is absolutely standard stuff for _any_ kernel submission whether tool-assisted or not. I don't think there's anything sinister there at all, and I think it's a really good way of _clearly_ communicating the fundamental requirements here. > > If tools permit you to generate a contribution automatically, expect > additional scrutiny in proportion to how much of it was generated. > > Every kernel patch needs careful review from multiple people. Please, OK so now you're contradicting the key point that we can reject slop out of hand, which is deeply counterproductive. A guy sends 500 tool-generated patches and now _according to the doc_ it needs _careful_ review from _multiple_ people? No. I also think this is stepping outside tooling documentation and essentially asserting things about kernel review in general that is really out of scope here. > don't start the public review process until after you have carefully > reviewed the patches yourself. If you don't have the necessary A useless person will 'review' it in advance without issue. Requiring _understanding_ is a lot clearer I think. > expertise to review kernel code, consider asking for help first before > sending them to the main list. Please no, maintainers have enough to do :) If you don't understand and, if a maintainer asks questions, can't defend what you've done, just don't send it at all. Simple, easy, clear. > > Ideally, patches would be tested but we understand that that's not > always possible. Be transparent about how confident we can be that the This is again stating some kind of policy that's very off-topic here. > changes don't introduce new problems and how they have been tested. This is actually bad - you're saying it's ok to send whatever, as long as you're transparent about how confident you are? Perhaps a clueless person is very confident the tooling in question got it right? Again I feel requiring understanding is a clearer criteria here. > > Bug reports especially are very welcome. Bug reports are more likely > to be dealt with if they can be tied to the individual commit which > introduced them. With new kinds of warnings, it is better to send > a few at a time at the start to see if they are a real issue or how > they can be improved. Again this feels very much out of scope. Overall your suggested change undermines the purpose of suggested addition - to _emphasise_ that we don't want nonsense submissions and to state this in _clear_ terms. I get where you're coming from, but I don't think there is any sinister undertone here - it's completely standard in kernel review for people to challenge what you've done and for you to need to be able to defend it. It doesn't imply aggression requiring defence or something like this, but rather very clearly setting some extremely minimal, sensible, ground rules. > > regards, > dan carpenter > Cheers, Lorenzo
