On Tue, 09 Jun 2026, Simona Vetter <[email protected]> wrote: > On Thu, May 28, 2026 at 10:14:41AM +1000, Dave Airlie wrote: >> Hey, >> >> Just want to give a heads-up that I intend to ask Roman to enable >> sashiko.dev AI patch review to be enabled for dri-devel in a week. >> Will request it replies to the list at for a trial period I think it >> balances time wasted best, but also allows people won't don't want to >> see the AI reviews to just bin it on their end in their mail filters. >> >> I also encourage the development of drm subsystem rules either via >> documentation updates or review prompts, >> https://github.com/masoncl/review-prompts > > Bit late my take, ignoring all the big picture questions (which are maybe > more suitable for the hallway track at next xdc - I do have strong > opinions on all this), the one reasons I think this is worth it is better > docs. > >> There has been some recent discussion >> https://lwn.net/Articles/1073583/ about merging the review prompts to >> the kernel or providing them as documentation. > > Like Jon Corbet also pointed out, whether it's because people feel more > comfy giving clear instructions to machines, or whether the faster cycle > possible with an llm getting everything wrong until you're extremely clear > with everything, very often code agents docs seem to be much better. So if > we can land those in the main docs and if this bot helps people (for as > long as the vc splurge may last) to improve the docs we have so it spits > out more useful replies, then I think it's worth to enable it.
I believe we don't write lots of detailed instructions for people, because it's a lot of work to write and maintain, and people just won't read or follow all the instructions anyway. That does lead to tribal knowledge and allows people to shout "it's not documented, how was I supposed to know", but tomes of detailed documentation isn't all that much better. It should be a balance. But LLMs won't get bored reading the instructions, and often actually follow them too. > For me though this does not remove the need for review, which is > fundamentally about ensuring that at least 2 human contributors have the > illusion (we all know that we're often not that good for real > understanding, this stuff is hard) of understanding a patch set, why we > need it, and how it goes about solving that problem. > > And at the meta level above that, the point of having that review is to > encourage collaboration across teams and companies, and improve our > community knowledge of how to and how not to write gpu drivers. Agreed. I have yet to see AI review with genuinely useful feedback about design or long-term subsystem goals. It's all details. Ditto for AI assisted patches, for that matter. One thing that's bugging me though is the absolute flood of review with "Pre-existing issues". 151 such review comments in the past week. Like, sure, we have pre-existing issues, but we can't block patches based on that, or we'll only be fixing pre-existing issues the rest of the year or so. Perhaps it's useful information as static analysis, but somehow it should be separated from patch review a bit better. BR, Jani. -- Jani Nikula, Intel
