On Thu, Jan 08, 2026 at 12:43:50PM +0100, Miguel Ojeda wrote: > On Thu, Jan 8, 2026 at 11:29 AM Lorenzo Stoakes > <[email protected]> wrote: > > > > I really don't think it is the case that maintainers can simplly dismiss an > > entire series like that. > > I think Dan was referring to all kinds of series, i.e. maintainers > have leeway to reject proposals, whether they are big or small and > whether they are new features or cleanups.
Sure, but I would say it's reasonable that there's a norm in place that rejecting series outright that aren't _trivially_ dismissable is bad if no technical objection is given right? The issue with LLMs is you can generate entirely novel series that aren't so trivially dimissible but could very well have other signals to hand e.g. brand new person, never done any kernel work before, sends a bunch of series at once etc. So maybe it's worth highlighting this? > > After all, the project works by trusting maintainers to do the right > thing (i.e. the best they can with the information and time at their > disposal), but sometimes there may not be concrete technical reasons. > > For instance, sometimes it is just a matter of bandwidth -- if > maintainers cannot maintain the code, and no one (that is trusted to > some degree) is willing to do so, then it would be a bad idea to take > the code anyway, even if the feature is great, whether LLM-generated > or not. Haha well mm does just merge stuff even if there isn't review capacity :) which I am arguing against presently as a very silly (and unworkable) thing to do. But that's another debate... > > That is also why it is often said that it is a good idea to contact > maintainers/community before developing completely a new feature etc. > etc. Yes, and we've seen in mm people come to the commnuity with a huge new patchset that is rejected. But it almost inevitably has _technical feedback_ as part of that reject that took time, something that the asymmetry of slop wouldn't permit so cleraly. > > So if a subsystem suddenly starts to get an onslaught of series like > you warn about, then they cannot be expected to review and give > technical feedback to everything, and they will need to prioritize > somehow (e.g. fixes), or try to get more maintainers, or raise the > issue in ksummit, etc. Right, but we also need to be able to take the sensible approach of simply not tolerating it. I mean if the contention is we already in effect can do this, then surely it's no harm to provide emphasis in the document no? > > At least, that is my take, i.e. we need to allow maintainers to adjust > as things come. And, of course, as a community, we can always reassess > as conditions change. See my other point about the tail wags the dog effect when an official kernel policy document appears to say 'open to business for LLMs'. Linus has already been quoted in the press I believe with his 'LLMs are just like any other tool'. I wish we didn't have to think about that, but we do. Anyway I'm submitting my suggested delta shortly. It's really not all that much different from the rest, just putting some emphasis on the slop aspect. > > Cheers, > Miguel Thanks, Lorenzo
