Live data from Hacker News

I don't want your PRs anymore

dpc.pw

131–140 of 148 posts

Re: I don't want your PRs anymore

#131

Yes, reviewing might take 1 hour but taking the PR and using it to guide an implementation also takes 1 hour. Thank your contributor; then, use the PR - and the time you’d have spent reviewing it- to guide a reimplementation.

My coworkers just let Claude review the PR now instead of reading the code. It seems the entire contract is broken now. Submitters use LLMs to generate the code and reviewers use LLMs to review it.

Quietly let that play out.

You’ll have a job for years to come :)

Re: I don't want your PRs anymore

#132
Same is true from the other side. With Claude Code I monkey patched some process fork issues in docling-serv the other day that prevented it from running on Windows. Has been running fine ever since. Should I realy write up a PR for something I basically half assed and everyone can do in 15 minutes?

Re: I don't want your PRs anymore

#133
post #123

I wrote an article a few months ago about how I expect open-source development to shift toward people no longer contributing code, but just contributing money, for the maintainers to purchase tokens to have AI ship a given feature request. It wasn't popular but I think it will hold: https://essays.johnloeber.com/p/31-open-source-software-in-t...

Why would they give money for tokens when they did not give money for dev time?

Re: I don't want your PRs anymore

#134

If they are willing to feed a bug report to their LLM, then perhaps they can also feed a bug report + PR to their LLM and not make a big fuss out it. Also, at the point they actively don’t want collaboration, why do open source at all? Strange times, these.

I'll take that source every time, even if you do not want my contributions.

Nowadays with genAI my powers to solve bugs and add features have unhyperbolically 100x'ed.

Re: I don't want your PRs anymore

#135

Maybe instead of submitting PRs, people should submit "prompt diffs" so that the maintainer can paste the prompt into their preferred coding agent, which is no doubt aware of their preferred styles and skills, and generate the desired commit themselves.

Why would anyone bother doing this, prompts are not code, they are not shareable artifacts that give the same results.

Prompts that are used to generate should thus be put in the repo.

Re: I don't want your PRs anymore

#136
post #30

I'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 bina…

> 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. My most negative experiences with free and open source contributions have been like that. The one maintainer who engaged with me until…

Ordinarily, I would agree. I don't do that with my other GitHub repositories nor at work.

But ghidra-delinker-extension's domain is unusually exacting. Mistakes or shortcuts there will cause undefined behavior of the exotic kind that can be exceedingly difficult to troubleshoot. The only way I've found to keep things from imploding is through unusually exacting quality standards that a drive-by contributor (who usually only cares about a particular ISA/object file combination on a given platform) can't be expected to match.

To be clear, I don't go silent when I receive a PR for this project. In those cases, I do engage with the contributor and give high-level feedback. But my spare time is finite and so is the other person's willingness to jump through all of my hoops.

Re: I don't want your PRs anymore

#137
post #56

Earlier quoted context omitted.

It seems like quite a tower of babel just waiting to happen.. All those libraries that once had thought go into tangled consequences of supporting new similar features and once had ways to identity for their security updates needed will all just be defective clones with 5%-95% compatibility for security exploits and support for integrations that are mostly right but a little hallucinated?

I think it's more likely that libraries will give way to specified interfaces. Good libraries that provide clean interfaces with a small surface area will be much less affected by thos compared to frameworks that like to be a part of everything you do. The JavaScript ecosystem is a good demonstration of a platform that is encumbered with layers that can only ever perform the abilities provivded by the underlying plat…

I could certainly see that direction earlier in some communities, but reaching agreement on specs seems like the opposite of where distributed low cost code writing is headed.. I.e. I like 20% of your OSS library and have one different opinion so I pull part of it in directly, change something, and ask an LLM to freshen it where that should mean what the LLM thinks I usually mean which is kind of like what some other people mean.

Re: I don't want your PRs anymore

#138
Great article! Two aspects I haven't seen addressed so far:

If people will no longer contribute to the source code directly, this means fewer people will be familiar with the code, meaning that:

- The bus factor becomes more significant. (Yes, this could partly be addressed by LLMs. But if the single maintainer disappears, this will still cause disruption until someone else takes over/forks the project.)

- Fewer people eye-ball the code for security issues (and for malicious changes by the maintainer). This, too, could be addressed by LLMs but are we all going to set up agents in the future that review all our 3rd-party dependencies' code?

Re: I don't want your PRs anymore

#139
post #30

I'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 bina…

> 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.

The PR system is great for reviewing changes within a dev team.

But, indeed, when its an external contribution, it kind of falls apart. It's unrealistic to expect from an external contributor, often a one time one, to know the ins and outs of a project (code standards, naming tastes, documentation, tests, ...)

I really like your workflow, and often did something similar in my projects (or merge in main, with subsequent fixes/realignments).

But I'm wondering if it could be smoothed out and normalized by Github/Gitlab/Forgeo, or maybe at the version control software level.

Re: I don't want your PRs anymore

#140

Earlier quoted context omitted.

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"?

Open-source is heavily community-oriented, and yes, I think that subverting the contributions of the community like this (and honestly, just kind of being a dick about it) is unethical, yeah. It erodes the fabric of open source, and will be detrimental not just to OSS, but to the field of software in the medium and long term for the reasons I stated earlier.

To your side note: "take" is a very common synonym for "thought"/"opinion"/"view" in the version (dialect? I guess?) of English I grew up with. If you're unfamiliar with it, that might be a regional or generational effect. I don't know. I'm not a linguist.

Post reply on HN