And since you can’t actually know for sure how much of a piece of code (or commit message) was written by AI you don’t really have a choice, do you? As time goes on and more people try to learn programming using AI a bunch of them may end up picking up some of its stylistic stuff. And if the submitter uses proper kernel formatting standards, will you be able to tell?
Honestly, seeing people go from concern trolling to what I like to call _concern farming_ has been utterly disappointing.
_concern farming_ is when people build entire crops of concerns with no intent to do anything other than fertilize them.
https://www.youtube.com/watch?v=NnV_cWeoo5Q
I really like your concern farming, will be using it going forward.
I watched a significant portion of that video, it represents what I expect well. You can't bury your head in the sand because an AI reported a bug, it's, potentially, still an exploitable bug. They can however raise the standard. They can require that reporting a bug comes with a fix, even if they reject the fix provided, it gives them an opportunity to evaluate that the bug is real, that someone put some effort in resolving it for the community (even if an LLM provided the fix); it gives something to evaluate the can benefit rather than only being a determent to the community.
I've sent a half dozen patches over the year to projects, I've always provided my perceived fix for the issue, occasionally they've been implemented as-is, and sometimes they were replaced outright with an alternate solution. I never really cared about the solution, just that the issues was resolved.
The first was a commercial library that dealt with multiple modems (interrupts and daughter cards)on dos based machines. They took the fix and integrated it and provided me with an updated library. Not much of a thank you, but the library was fixed.
More recent ones was another commercial library, open source but proprietary, and they sat on it for 3 months waiting for me to fix it their way, before the accepted it as-is and released appropriately adjusted patch. (I'm not their employer or employee, their complaints were tedious undefined rules. I fixed the bug and had working code. I waited them out.)
Good responses, bad responses, none of them mattered, what did matter to me, and others, is the developers involved cared enough to eventually implement the right fix for their codebase. The bugs need to go. Set the ego aside and fix it.
https://github.com/anomalyco/opencode/pull/51337
The Pi dev who's handling my request there is just not getting it.
I expect the participants in this discussion to grumble for a few days, then continue working amically together.
I think he's very wrong on this, though.
But people will not stop bringing it up over and over again. They just had the kernel summit where it was discussed again.
I imagine he’s REALLY REALLY tired of people continuing to try to start it up again.
Given Linus’ stance that it’s just a tool, which makes sense as a position, it’s really odd to ban only that one tool especially when you know your ban is completely useless to “make a statement”.
Just interesting to see how different people handle these situations.
He’s someone who should know the policy.
Linus agreed that the “assisted by“ tag that was invented for AI wasn’t working and it got removed. There was already discussion that lead to this.
So here he is, again (presumably), taking this patch series removing that tag to try to push the topic again. That kernel summit I mentioned was 6 days ago as I type. LWN reported this was talked about.
I’m sure Linus would ignore me (a nobody) posting. Or someone who has made a few patches over the years.
I think Pinchart is high enough in the rankings Linus felt this was needed, or maybe more likely couldn’t hold his frustration.
I can’t imagine how frustrated by and tired of this topic Linus must be.
The combativeness is a feature, not a bug.
For reals though: Comparing AI to editors or compilers is a massive false equivalency.