[hnarn]

Why would you solve an issue like this and then not supply a patch upstream, or at the very least contact someone that could? It seems to be like the FLOSS equivalent of posting about a problem on a forum and then replying "nvm, solved it".

[Avamander]

Primarily because OP can't verify that the patch is truly correct. There's also the fact that anything LLM-generated will likely be frowned upon (for the same reason).

With some effort OP could review it manually and then try to submit it though.

But QEMU uses a mailing list for development, it's tedious to set up and then later keep track of. I now fundamentally refuse to contribute to projects that use mailing lists for development, the effort it takes and the experience is just so horrible.

Especially if it's a small patch that doesn't concern anyone (any big sponsors), you'll probably never get a response. Things get lost easily.

[0xbadcafebee]

1) The upstream only supports latest versions of SDK, they're not going to accept a patch to make the app work on an older SDK

2) I sent the patch to MacPorts which is what I was using and also had failed builds, and the maintainers closed my submission as a dupe (of a ticket which actually didn't have the full patch nor anyone testing it). I offered to do more investigation, no response

3) It's open source, I really don't owe anyone anything, nor they me

[ang_cire]

As the other person said, a LOT of github projects with medium-large contributor bases are extremely hostile to AI code contributions. Some of this is about 'slop' coding not being up to par. A lot of it is also about people making their github contributions part of their resume, and thus not wanting the 'devaluation' of their time investments by AI contributions.

[SpaceNoodled]

This comment works a lot better without the scare quotes.

[circularfoyers]

I would hazard a guess that it's because there's been many debates about contributing PRs that might be perceived as AI slop. Not saying that's the case here, but it's possible the fix might be a poor one, not follow the project's guidelines, or one which the contributor doesn't fully understand, but doesn't care because it fixed the issue. I would guess the better approach would be to submit a bug report with the same information the LLM used, and maybe suggest there the fix the LLM provided. Unless this really was a tiny patch and none of the above concerns applied.