Hello Jarkko, On Fri, May 22, 2026 at 03:44:05PM +0300, Jarkko Sakkinen wrote: > On Fri, May 22, 2026 at 10:16:39AM +0200, Uwe Kleine-König (The Capable Hub) > wrote: > > On Fri, May 22, 2026 at 12:43:23AM +0300, Jarkko Sakkinen wrote: > > > Clean up can be side-effect but not a purpose. > > > > Oh, I disagree. Having code in a state where you can easily see what > > happens helps to concentrate on the parts that are more complicated. So > > it's a win for maintenance and lowering the entry bar for people who are > > not used to Linux kernel code. There are parts in the kernel that are > > complicated, and we won't get rid of them, because operating systems are > > complicated. But my POV here is that making it easier where it's > > possible is a good thing and a reason for itself. You might call that a > > paper cut only, but these add up. > > > > Also with the union in i2c_device_id the compiler warns you if some code > > is lacking a "const". So it becomes harder to make mistakes, this is > > also a reason that in my book is good enough for itself. > > Actually what I said is more important than ever before given AI agents. > > If I start to accept pure cleanups from humans it's like invitiation for > slop. This is actually an area where it would be advicable for any > maintainer to tighten the acceptance criteria.
I also disagree here. If a patch improves something (be it security, runtime behaviour or maintainability) that should be reason enough to accept it. If it's created by AI (or a by a newbie with the help of AI) that's a reason to make sure the patch has the intended effect, but that's essentially the same for any patch. I agree that AI might get problematic if it floods maintainers and effectively becomes a DOS attack to maintainer resources. But that doesn't necessarily makes the patches it proposes bad. Best regards Uwe
signature.asc
Description: PGP signature
