Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I close pull requests

jeffgeerling.com

Post reply on HN
Print view View original

21–30 of 188 posts

Re: Why I close pull requests

#21

Post by kevin_b_er »

caconym_ wrote: post #15
hk__2 wrote: post #11

Earlier quoted context omitted.

You should report this to the blog author; not to HN readers.

My assumption is that the OP, "geerlingguy", and the post's actual author Jeff Geerling, are one and the same. Not unreasonable, I think. If he wants to post his work on HN and not read the discussion (which is obviously going to be relevant to his work), that's on him.

https://news.ycombinator.com/user?id=geerlingguy https://keybase.io/geerlingguy

And the assumption is accurate. You can read their HN profile and see the keybase.io connections to the website, HN account, and to github.

Re: Why I close pull requests

#22

Post by asdkjfsad888 »

alaaibrahim wrote: post #18
makecheck wrote: post #2

Also, don’t send requests out of the blue. The original maintainer has to know that you’re working on something. One reason is that your changes might collide spectacularly with other planned changes you weren’t aware of. Another reason is that the maintainer might say “no” to the entire idea , much less the implementation, and save you time. The mere creation of a fork isn’t a sufficient signal, either; the project…

Why Not? I see a problem that I can fix, I do that, and then send it back to the original maintainer, making sure that I'm not breaking tests if they exist, and providing a good description of the change. Then it's up to the maintainer to either merge it, or throw it away. Of course, I don't have any problem with getting my PRs closed, I'm not the one who would end up maintaining the code.

> I see a problem that I can fix...

Remember, they said "out of the blue" which means "without prior contact to discuss doing so."

This exact reason was explained in the parent post: maybe the maintainers and project owners don't see it as a problem or are already working on something.

It's not just about being a machine that can crank out fixes to the individual issues in software wherever you see them. It's about participating in a social project intended to fix a larger scale problem.

> Of course, I don't have any problem with getting my PRs closed, I'm not the one who would end up maintaining the code.

A reason alone not to send PR's "out of the blue". If you're just looking to pump and dump, I'd rather not involve you in the process, only to have to do work to fix/rm code down the road.

But I mean, above all, it's your time to waste.

Re: Why I close pull requests

#23

Post by dclowd9901 »

You know what would be cool? If I could create a fork off the project i was using. Then I write a feature I need in that project. it becomes a PR, but then the fork is also automatically (if possible) updated whenever the main branch is updated. If it can't be updated automatically you are notified to update your fork against the upstream changes. This would have many benefits, including easy testing of PRs, forks that don't stale, and overall helping closing the loop on open PRs.

Re: Why I close pull requests

#24

Post by asdkjfsad888 »

rpedela wrote: post #14
marcosdumay wrote: post #8

Earlier quoted context omitted.

The problem is on the other side. If you don't want the push, the sender just wasted a some work.

Not necessarily. They obviously need that change so it wasn't wasted. However they have to maintain the change themselves if it isn't merged.

How do you know they obviously need the change by making a decision away from the project management discussions?

Perhaps a solution has been discussed and is incoming from a regular developer?

They could deprecate the module where the change is "obviously" needed in a larger fix.

Frame it a different way: You're basing the needs of a project on your view of it, which, minus discussing things with project mgmt beforehand, may be incomplete.

Re: Why I close pull requests

#25

Post by Nadya »

asdkjfsad888 wrote: post #24
rpedela wrote: post #14

Earlier quoted context omitted.

Not necessarily. They obviously need that change so it wasn't wasted. However they have to maintain the change themselves if it isn't merged.

How do you know they obviously need the change by making a decision away from the project management discussions? Perhaps a solution has been discussed and is incoming from a regular developer? They could deprecate the module where the change is "obviously" needed in a larger fix. Frame it a different way: You're basing the needs of a project on your view of it, which, minus discussing things with project mgmt before…

You completely misunderstood who was needing the fix. In this case, it was the person who spent time fixing it. They likely fixed it because they need the fix.

Doesn't matter if the entire module becomes deprecated. They'll stay back with their fix (likely). Doesn't matter if another solution is inbound, they needed the fix now and not when a patch lands.

And since they already took the time to fix it - little time is lost sending a PR, regardless if it gets merged or not. If it is merged? Sweet you helped the project out (most likely). If not? Well a small bummer that you'll need to maintain your own patch(es).

Re: Why I close pull requests

#26

Post by manarth »

makecheck wrote: post #2

Also, don’t send requests out of the blue. The original maintainer has to know that you’re working on something. One reason is that your changes might collide spectacularly with other planned changes you weren’t aware of. Another reason is that the maintainer might say “no” to the entire idea , much less the implementation, and save you time. The mere creation of a fork isn’t a sufficient signal, either; the project…

Given the scenario that I am using open-source software X, and that I have made changes to the software to suit my requirements, and that I believe those changes might be useful to others, I can either:

1. Contribute those changes up-stream, by sending a pull request.

2. Publicise the changes, by keeping my fork, and/or talking about it in a blog post.

3. Keep quiet, and say nothing.

4. Send an email to the original developer, suggesting I may have some useful changes, and asking whether I should send a PR.

If I start working on changes without notifying the original maintainer, well, I might do work that's useless, that maintains no value, that isn't sustainable. But that's my loss.

If I send a PR, the net loss is the maintainer's time to review my PR (if they choose to).

Many open-source contributions stem from sending PRs out of the blue. You're right to say that it can be an inefficient mechanism in some circumstances; it's just that a lot of developers are OK with that.

Re: Why I close pull requests

#27

Post by fourthark »

I know it's not best practice, but I leave them open. For years.

They may be fixable, they may be useful to someone. I've no need to reject them unless I really think they're a bad idea.

I'm sure this can be frustrating to users and contributors, but I also see it as a way of encouraging forks. "I haven't had a chance to review this, but you might try PR #NN..."

The most useful ones get replaced by better versions by other people, and eventually merged.

Re: Why I close pull requests

#28

Post by tedunangst »

mikeash wrote: post #20
Skuzzzy wrote: post #5

Earlier quoted context omitted.

Padding resumes is a bit cynical there are many good reasons to make a fork for oneself. Like ensuring you have code you depend on in the event the project is deleted

I've also seen people who don't understand how his stuff works, and fork projects before cloning them because they think that's the process. A relatively small number of clueless people could result in a lot of pointless forks.

The big button does say "fork me on github" after all.

Re: Why I close pull requests

#29

Post by StavrosK »

manarth wrote: post #26
makecheck wrote: post #2

Also, don’t send requests out of the blue. The original maintainer has to know that you’re working on something. One reason is that your changes might collide spectacularly with other planned changes you weren’t aware of. Another reason is that the maintainer might say “no” to the entire idea , much less the implementation, and save you time. The mere creation of a fork isn’t a sufficient signal, either; the project…

Given the scenario that I am using open-source software X, and that I have made changes to the software to suit my requirements, and that I believe those changes might be useful to others, I can either: 1. Contribute those changes up-stream, by sending a pull request. 2. Publicise the changes, by keeping my fork, and/or talking about it in a blog post. 3. Keep quiet, and say nothing. 4. Send an email to the original…

If you've already made the changes, then by all means, just send a PR. The worst thing that can happen is that it won't get merged.

If you're considering doing some work, please talk to the maintainer first. Otherwise it might lead to unhappiness all around, because, as a maintainer, I don't like turning down all this work you've done for free any more than you do, but there's not much choice when it's a net negative (for any of the reasons in the article).

Post reply on HN