It's like finding out the open source community's got black mold

[mcc@mastodon.social]

It's like finding out the open source community's got black mold

[geoffwozniak@masto.hackers.town]

@mcc Goddammit.

[uep@timeloop.cafe]

@mcc AIsbestos.

[sbseltzer@peoplemaking.games]

@mcc I didn't even know you could block users on github :O

[mcc@mastodon.social]

@sbseltzer u cann

[leo@60228.dev]

@mcc@mastodon.social uhh are you sure

[sbseltzer@peoplemaking.games]

@mcc It's a bit sad to think that warning will remain even if the related code is replaced by humans since history is immutable (unless rewritten but you'd basically never do that on an OSS project)

[nivex@tenforward.social]

@mcc @xgranade (╯°□°）╯︵ ┻━┻

[leo@60228.dev]

@mcc@mastodon.social oh this is just a github moment. well the one commit is an obviously correct one-line change that was PR'd

[xgranade@wandering.shop]

@mcc Not to mention people who are very, very excited to huff black mold spores.

[leo@60228.dev]

@mcc@mastodon.social i have no idea why the PR author apparently needed claude to change literally a single function call from panic to zfs_panic_recover, but.

[algernon@come-from.mad-scientist.club]

@leo @mcc that view only shows the committer. It doesn't show co-authored commits, as far as I can tell.

[mcc@mastodon.social]

@leo @algernon Ah.

I deleted because if there was any chance of error, I didn't want to leave it up, but a PR'd one line change is still enough for me to complain.

The thing is, my understanding is you have to use the tool in a particular way for it to actually create the committed-with header. For more complex uses I believe the header does not show up.

[mcc@mastodon.social]

@leo @algernon So

1. It's installed on at least one dev's computer

2. The presence of a header-disclosed commit could imply non-disclosed commits possibly from the same developer

3. The project is not filtering for such code even when it's disclosed

[det@critter.cafe]

@mcc their vibe-coded slop (zfs) versus my honorable, ornately written tapistry (xfs)
sgi stays winning (i am gonna be shattered if it turns out xfs ALSO uses ai code, my goats had failed me if so)

[mcc@mastodon.social]

@det I'm a bit concerned about RHEL.

[leo@60228.dev]

@mcc@mastodon.social @algernon@come-from.mad-scientist.club (it appears to have been the only commit by that user in 9 years, fwiw)

[leo@60228.dev]

@mcc@mastodon.social @algernon@come-from.mad-scientist.club but also i mean in this case not merging it would be weird, would the alternative be to leave the bug there out of spite?

[mcc@mastodon.social]

@leo @algernon If it were my project i would ban the contributor. One line or not they are not following the DCO as written which this project requires. So either the DCO is violated, the DCO has a "you can do anything as long as it's through a hole in a sheet" exception for AI, or the DCO is not enforced at all, or most likely this crept up on OpenZFS and they have never thought about this and did not notice the claude line.

[mcc@mastodon.social]

@leo @algernon As for leaving it broken, if it was a one line bug, once discovered their PR is apparently not needed.