ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Chris Mason <clm@meta.com>,
	ksummit@lists.linux.dev, Dan Carpenter <dan.carpenter@linaro.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Rob Herring <robh@kernel.org>
Subject: Re: [MAINTAINERS / KERNEL SUMMIT] AI patch review tools
Date: Thu, 9 Oct 2025 09:40:19 -0300	[thread overview]
Message-ID: <aOetMx2M58NYfmP3@x1> (raw)
In-Reply-To: <2c04a89f-abd5-48c6-abfc-2e71d24e913f@lunn.ch>

On Wed, Oct 08, 2025 at 10:37:51PM +0200, Andrew Lunn wrote:
> > This raises the interesting and important question of how to get patch
> > submitters to follow a recommended workflow. We routinely get patches
> > that produce checkpatch errors that are clearly not false positives.
> > Rob Herring implemented a bot to run checks on device tree bindings and
> > device tree sources because lots of patches fail those checks. I'm sure
> > there are lots of other examples that have led maintainers to automate
> > checks on the receiver's side, through various types of standard CIs or
> > hand-made solutions. Submitters should run more tests, how to get them
> > to do so is a broader question.
 
> The netdev CI tooling is available from github. You can run it as a
> docker image. So it is possible for a netdev developer to run the same
> tests as netdev Maintainers do. Maybe we need more subsystems to make
> their CI tooling available to their developers so they can be run
> locally?
 
> It has also been pointed out elsewhere, b4 is gaining more testing
> capabilities. We should keep building this out, making subsystem
> tooling more subsystem specific, while b4 can do all the standard
> stuff we expect all developers to do before submission.

Yeah, if b4 would run these then the process would be streamlined,
great.

But the good thing would be to maybe have a CI see patches,
test/LLM/lint/kitchen sink it/etc them and sign them, giving it a "seal
of approval", or some brownie point that would then make procmail (or
equivalent) move this to a "special folder", that would be the first one
maintainers would read in the morning.

Maintainers would receive everything, as today, all of lkml/etc, but
some classification would be done so that they would look first at the
"good stuff".

I'd really love if running 'make -C tools/perf build', 'perf test' and
https://github.com/acmel/linux-tools-container-builds, after applying a
series would complete successfully. One can dream :-)

Even if all of this was done, I think b4 should do as you suggest,
checking one last time.

- Arnaldo

  reply	other threads:[~2025-10-09 12:40 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-08 17:04 Chris Mason
2025-10-08 17:20 ` Konstantin Ryabitsev
2025-10-08 18:11   ` Sasha Levin
2025-10-08 18:35   ` Chris Mason
2025-10-08 17:57 ` Bart Van Assche
2025-10-08 18:04   ` Chris Mason
2025-10-08 18:14     ` Bart Van Assche
2025-10-08 18:42       ` Chris Mason
2025-10-08 21:08     ` Kees Cook
2025-10-09  1:37       ` Chris Mason
2025-10-08 18:33 ` Sasha Levin
2025-10-09  1:43   ` Chris Mason
2025-10-09 14:49     ` Paul E. McKenney
2025-10-08 19:08 ` Andrew Lunn
2025-10-08 19:28   ` Arnaldo Carvalho de Melo
2025-10-08 19:33     ` Laurent Pinchart
2025-10-08 19:39       ` Arnaldo Carvalho de Melo
2025-10-08 20:29         ` Andrew Lunn
2025-10-08 20:53           ` Mark Brown
2025-10-09  9:37         ` Laurent Pinchart
2025-10-09 12:48           ` Arnaldo Carvalho de Melo
2025-10-08 19:29   ` Laurent Pinchart
2025-10-08 19:50     ` Bird, Tim
2025-10-08 20:30       ` Sasha Levin
2025-10-09 12:32         ` Arnaldo Carvalho de Melo
2025-10-08 20:30       ` James Bottomley
2025-10-08 20:38         ` Bird, Tim
2025-10-08 22:21           ` Jiri Kosina
2025-10-09  9:14           ` Laurent Pinchart
2025-10-09 10:03             ` Chris Mason
2025-10-10  7:54               ` Laurent Pinchart
2025-10-10 11:40                 ` James Bottomley
2025-10-10 11:53                   ` Laurent Pinchart
2025-10-10 14:21                     ` Steven Rostedt
2025-10-10 14:35                   ` Bird, Tim
2025-10-09 14:30             ` Steven Rostedt
2025-10-09 14:51               ` Andrew Lunn
2025-10-09 15:05                 ` Steven Rostedt
2025-10-10  7:59                 ` Laurent Pinchart
2025-10-10 14:15                   ` Bird, Tim
2025-10-10 15:07                     ` Joe Perches
2025-10-10 16:01                       ` checkpatch encouragement improvements (was RE: [MAINTAINERS / KERNEL SUMMIT] AI patch review tools) Bird, Tim
2025-10-10 17:11                         ` Rob Herring
2025-10-10 17:33                           ` Arnaldo Carvalho de Melo
2025-10-10 19:21                           ` Joe Perches
2025-10-10 16:11                       ` [MAINTAINERS / KERNEL SUMMIT] AI patch review tools Steven Rostedt
2025-10-10 16:47                         ` Joe Perches
2025-10-10 17:42                           ` Steven Rostedt
2025-10-11 10:28                         ` Mark Brown
2025-10-09 16:31               ` Chris Mason
2025-10-09 17:19                 ` Arnaldo Carvalho de Melo
2025-10-09 17:24                   ` Arnaldo Carvalho de Melo
2025-10-09 17:31                     ` Alexei Starovoitov
2025-10-09 17:47                       ` Arnaldo Carvalho de Melo
2025-10-09 18:42                     ` Chris Mason
2025-10-09 18:56                       ` Linus Torvalds
2025-10-10 15:52                         ` Mauro Carvalho Chehab
2025-10-09 14:47             ` Bird, Tim
2025-10-09 15:11               ` Andrew Lunn
2025-10-09 17:58               ` Mark Brown
2025-10-09  1:15         ` Chris Mason
2025-10-08 20:37     ` Andrew Lunn
2025-10-09 12:40       ` Arnaldo Carvalho de Melo [this message]
2025-10-09 14:52 ` Paul E. McKenney
2025-10-10  3:08 ` Krzysztof Kozlowski
2025-10-10 14:12   ` Chris Mason
2025-10-31 16:51   ` Stephen Hemminger
2025-10-14  7:16 ` Dan Carpenter

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=aOetMx2M58NYfmP3@x1 \
    --to=acme@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=ast@kernel.org \
    --cc=clm@meta.com \
    --cc=dan.carpenter@linaro.org \
    --cc=ksummit@lists.linux.dev \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=robh@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox