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

31–40 of 188 posts

Re: Why I close pull requests

#31

Post by akerl_ »

asdkjfsad888 wrote: post #22
alaaibrahim wrote: post #18

Earlier quoted context omitted.

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 p…

The post calls out major changes as deserving a chat first. My primary workflow that results in PRs is: 1) I find an interesting project, 2) I find something it doesn't do the way I want (a bug, or a config tweak), 3) I patch my fork to fix that, 4) I open up a PR incase the maintainer does think it's worth merging into upstream.

What's the upside of me opening an issue first to chat about it? The maintainer still has to burn the time to think about it, but without seeing the code that I'm proposing, which is already written because I already needed it to scratch my itch.

If they think it's worth of merging, woo, we merge it. If they want the problem fixed a different way, cool, one of us writes the PR that makes that happen. If they don't want the change, I keep using my fork.

Re: Why I close pull requests

#32

Post by ageofwant »

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.

How are you supposed to do it otherwise ? Where else are you going to push your commits to ? Its silly to clone, fiddle with git config, make a new git repo on github/lab and then push to your new 'manual fork'. Just use the fork button.

Re: Why I close pull requests

#33

Post by Manishearth »

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…

I think a better way to put this is "don't send requests out of the blue if you care about them getting merged".

I often hack on software that I use to make it do something I need. I then try to upstream the code, if I think that it's something others may want too. I don't particularly care about it being merged -- my attitude to this is "Here's something I found useful, if other people think it's good please take it". I'm willing to put some effort into cleaning up the patch to make it submission-worthy, but if it doesn't get merged, it doesn't get merged. I'll keep it up in a fork, and that's about it.

I don't care about it getting upstreamed enough that I will open a dialogue before I start to work on it. It's a feature I want, and I will be working on it regardless of how the dialogue goes down. The only way a dialogue can help me is by giving me implementation advice, but quite often I've already figured out a way to do it which is sufficient for my purposes (hacky or otherwise).

If there's a feature that you actually care about existing in upstream, then you should totally open an issue first and discuss it.

Re: Why I close pull requests

#34

Post by Sir_Cmpwn »

I also maintain a great number of projects (perhaps more) and generally I give feedback on why a PR is unacceptable and leave it open until it's resolved. Sometimes I'll close it a year or two later.

Re: Why I close pull requests

#35

Post by mikeash »

ageofwant wrote: post #32
mikeash wrote: post #20

Earlier quoted context omitted.

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.

How are you supposed to do it otherwise ? Where else are you going to push your commits to ? Its silly to clone, fiddle with git config, make a new git repo on github/lab and then push to your new 'manual fork'. Just use the fork button.

99% of the time, when I clone an open source repository, I just want to use it, not make new commits to it.

Obviously, if you want your own copy to commit to, then use the fork button. That's what it's for. But lots of people use the fork button even when their use case is read-only.

Re: Why I close pull requests

#36

Post by flurdy »

fourthark wrote: post #27

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…

That depends on if you respond with a comment that indicates it's not likely to be merged. Then it is understandable, otherwise it is just rude and confusing.

Re: Why I close pull requests

#37

Post by mikepurvis »

dclowd9901 wrote: post #23

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 th…

I don't know about "automatically", since all the hashes would change, but I definitely do wish that Github had better tools for managing long term forks, especially web workflows for:

- rebase this branch on upstream

- resolve merge/rebase conflicts

- make my master be upstream's master with PRs X, Y, and Z applied to it in that order.

I find the last one in particular to be awful, where I'm iterating on multiple PRs with an upstream, and keeping them separate for the sake of review, but wanting to test as a group to validate the end-to-end functionality. It can be a huge hassle cherry picking and rebasing commits between branches.

Re: Why I close pull requests

#38

Post by geerlingguy »

StavrosK wrote: post #29
manarth wrote: post #26

Earlier quoted context omitted.

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…

Exactly. Too often I get a large PR that I call a 'code dump'. at least give a couple paragraphs of explanation behind the changes. Sometimes a conversation can start in a PR, but it's more rare that results in merged code than if there was an issue first.

Re: Why I close pull requests

#39

Post by greglindahl »

Nadya wrote: post #25
asdkjfsad888 wrote: post #24

Earlier quoted context omitted.

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…

This is an odd way of thinking about it. As a user of software, I like fixing it for my needs but I'd rather make the change in a way that the maintainer will accept, so that I don't have to maintain my patch. That means I'll tend to open an issue first, explain that I'm willing to submit a PR, and see if the maintainer wants to give me guidance.

Re: Why I close pull requests

#40

Post by CaptSpify »

lgas wrote: post #16
NickBusey wrote: post #12

Earlier quoted context omitted.

I'm not sure if you're just being pedantic, but "the bus factor is high" in this instance means there is a high level of risk to the health of the OSS projects he maintains if he were to get hit by a bus.

I don't think he's being pedantic, it's the opposite of the general usage. The bus factor is the number of people that have to be hit by a bus to cause real problems for your project. Higher is better.

Indeed!

> The "bus factor" is the minimum number of team members that have to suddenly disappear from a project before the project stalls due to lack of knowledgeable or competent personnel.

https://en.wikipedia.org/wiki/Bus_factor

Post reply on HN