turning on sashiko.dev for dri-devel

turning on sashiko.dev for dri-devel

[Dave Airlie]

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

There has been some recent discussion
https://lwn.net/Articles/1073583/ about merging the review prompts to
the kernel or providing them as documentation.

Dave.

Re: turning on sashiko.dev for dri-devel

[Simona Vetter]

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.

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.

Anyway, firehose is on, let's see what happens.
-Sima
-- 
Simona Vetter
Software Engineer
http://blog.ffwll.ch

Re: turning on sashiko.dev for dri-devel

[Jani Nikula]

On Tue, 09 Jun 2026, Simona Vetter <simona.vetter@ffwll.ch> 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