Given that submitters are just using LLMs to produce the PR anyway, it makes sense that the author can just run that prompt himself. Just share the 'prompt' (whether or not it is actually formatted as a prompt for an LLM), which is not too different than a feature request by any other name.
I don't want your PRs anymore
21–30 of 148 posts
Re: I don't want your PRs anymore
#22Thats fine, the cost for me to re-implement your code is nearly zero now, I don’t have to cajole you into fixing problems anymore.
This is an unethical take, and long-term and at scale, an unsustainable/impractical one. This kind of mindset results in tool fragmentation, erosion of trust, and ultimately worse quality in software.
So you're saying people forking open source software is "unethical"? What is open source then? Just a polite offer that it is rude to accept?
As a sidenote: what's with the usage of "take" to designate an opinion instead of the word "opinion" or "view"?
Re: I don't want your PRs anymore
#23I agree with this mindset. Instead of submitting code diffs, we should be submitting issues or even better tests that prove that bugs exist or define how the functionality should work.
Re: I don't want your PRs anymore
#24Couldn't you also just have an LLM review the PR and quickly fix any issues? Or even have it convert the PR into a list of specs, and then reimplement from there as you see fit?
I guess my point being that it's become pretty easy to convert back and forth between code and specs these days, so it's all kind of the same to me. The PR at least has the benefit of offering one possible concrete implementation that can be evaluated for pros and cons and may also expose unforeseen gotchas.
Of course it is the maintainer's right to decide how they want to receive and respond to community feedback, though.
Re: I don't want your PRs anymore
#25The author sounds like he actually responds to feature requests, though. Typical behavior I'm seeing is that the maintainer just never checks the issue tracker, or has it disabled, but is more likely to read PR's.
Re: I don't want your PRs anymore
#26Thats fine, the cost for me to re-implement your code is nearly zero now, I don’t have to cajole you into fixing problems anymore.
The cost of forking open source code was always effectively zero.
It's not really, because you now have the cost of maintaining that fork, even if it's just for yourself.
Re: I don't want your PRs anymore
#27I think every maintainer should be able to say how they want or don't want others to contribute.
But i feel like it was always true that patches from the internet at large were largely more trouble then they were worth most of the time. The reason people accept them is not for the sake of the patch itself but because that is how you get new contributors who eventually become useful.
Re: I don't want your PRs anymore
#28Re: I don't want your PRs anymore
#29> On top of that, there are a lot of personal and subjective aspects to code. You might have certain preferences about formatting, style, structure, dependencies, and approach, and I have mine. 95% of this is covered by a warning that says "I won't merge any PR that a) does not pass linting (configured to my liking) and b) introduces extra deps" > With LLMs, it's easier for me to get my own LLM to make the change and…
> 95% of this is covered by a warning that says "I won't merge any PR that a) does not pass linting (configured to my liking) and b) introduces extra deps" Maybe I'm not up to date with the bleeding edge of linters, but I've never seen one that adequately flags let out = [] for(let x of arr){ if(x > 3){ out.append(x + 5) } } Into let out = arr .filter(x => x > 3) .map(x => x + 3) There's all sorts of architectural de…
Indeed, yours has both more allocations and a bug (+3 instead of +5)
Re: I don't want your PRs anymore
#30I've been on both ends of this.
As the maintainer of ghidra-delinker-extension, whenever I get a non-trivial PR (like adding an object file format or ISA analyzer) I'm happy that it happens. It also means that I get to install a toolchain, maybe learn how to use it (MSVC...), figure out all of the nonsense and undocumented bullshit in it (COFF...), write byte-perfect roundtrip parser/serializer plus tests inside binary-file-toolkit if necessary, prepare golden Ghidra databases, write the unit tests for them, make sure that the delinked stuff when relinked actually works, have it pass my standards quality plus the linter and have a clean Git history.
I usually find it easier to take their branch, do all of that work myself (attributing authorship to commits whenever appropriate), push it to the master branch and close the PR than puppeteering someone halfway across the globe through GitHub comments into doing all of that for me.
Conversely, at work I implemented support for PKCS#7 certificate chains inside of Mbed-TLS and diligently submitted PRs upstream. They were correct, commented, documented, tested, everything was spotless to the implicit admission of one of the developers. It's still open today (with merge conflicts naturally) and there are like five open PRs for the exact same feature.
When I see this, I'm not going to insist, I'll move on to my next Jira task.