All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simona Vetter <simona.vetter@ffwll.ch>
To: Dave Airlie <airlied@gmail.com>
Cc: dri-devel <dri-devel@lists.freedesktop.org>,
	Simona Vetter <simona@ffwll.ch>,
	Roman Gushchin <roman.gushchin@linux.dev>
Subject: Re: turning on sashiko.dev for dri-devel
Date: Tue, 9 Jun 2026 17:07:06 +0200	[thread overview]
Message-ID: <aigsGomurnOVWLVO@phenom.ffwll.local> (raw)
In-Reply-To: <CAPM=9tyvm1jAX5udJ8OU+39XzwZRATjjhHAWDn7kJug+NZKBuA@mail.gmail.com>

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

      reply	other threads:[~2026-06-09 15:07 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-28  0:14 turning on sashiko.dev for dri-devel Dave Airlie
2026-06-09 15:07 ` Simona Vetter [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aigsGomurnOVWLVO@phenom.ffwll.local \
    --to=simona.vetter@ffwll.ch \
    --cc=airlied@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=roman.gushchin@linux.dev \
    --cc=simona@ffwll.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.