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

51–60 of 188 posts

Re: Why I close pull requests

#51

Post by fourthark »

flurdy wrote: post #36
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.

Well, I usually say that it needs tests, and in my crowd that's equivalent. :-/

Re: Why I close pull requests

#52

Post by UK-AL »

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 work on many things for software projects for my own personal gain. I don't particularly care if someone is planning to do something similar in the future. I need this thing now, for whatever project I'm currently doing.

I implement it, and sometimes I may send a PR to see if the maintainer wants it. I don't particularly care if it gets accepted or not. However I think giving them the option to pull if they want it, is a good idea.

Re: Why I close pull requests

#53

Post by geerlingguy »

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.

I'm here now... had to put my kids to bed; some nights it takes an hour or two (nights when all three act like the Tasmanian devil!).

It's fixed now :)

Re: Why I close pull requests

#54

Post by StavrosK »

manarth wrote: post #43
StavrosK wrote: post #29

Earlier quoted context omitted.

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…

as a maintainer, I don't like turning down all this work you've done for free I empathise with that perspective, and I appreciate any work that an open-source maintainer does to contribute to a project, so thank you. I must confess, I often submit patches without prior warning or discussion. They almost always come out of client work: I've been asked to deliver a requirement, so I do what I have to do to deliver that…

That's pretty much the best scenario, I think. If you won't be offended by the fact that I may not consider the PR appropriate for the codebase, I appreciate the time you took to post it for consideration (and thank you!).

Re: Why I close pull requests

#55

Post by fdsfsaa »

stinkytaco wrote: post #50
fdsfsaa wrote: post #47

Earlier quoted context omitted.

Requiring permission to do work is the enemy of progress and engineering dignity. It creates a presumption of incompetence and an atmosphere of low trust that punishes people who want to push the envelope of what's possible. Google's design document culture is bad. Google has succeeded in spite of it. In my experience, having worked at many large tech companies, design documents obfuscate, not enlighten. They become…

I can't comment on Google's culture, but: >Design documents turn every feature into a half-assed, lowest-common-denominator risk-minimized shell of itself. Sounds like a sentence written by someone who is an engineer and not a support staff or a user, i.e the people who have to deal with the fallout of every feature change and every engineering decision. I could just as easily substitute "feature driven design" into…

> Sounds like a sentence written by someone who is an engineer and not a support staff or a user

Do support staff and users sign off on design documents? "No" is the universal answer. Are you claiming that engineers aren't reasonable human beings who can take support staff and user concerns into account on their own? What makes you think the people reviewing design documents can do that?

Is it that you just trust a subset of engineers to understand the big picture? Are most engineers just drones? You shouldn't hire people who don't give enough of a shit to take the big picture into account.

I am an engineer. I am also a user. I do support my software. I've been programming for twenty years. I find that "rigorous scrutiny" hurts more often than it helps. Maybe this rigid scrutiny was more appropriate in a world with release cycles measured in years, but we don't live in that world anymore. When you ship every week, you can easily undo mistakes, and you're better off erring toward iteration.

Re: Why I close pull requests

#56

Post by zardeh »

fdsfsaa wrote: post #47
yegle wrote: post #13

At Google, if you want to implement new features (or large refactoring), you'll need to write a design doc. In which, you should answer questions your reviewers might ask (common questions like: why do you want to do this, what are the alternatives, how components interactive with each other before/after your change). This is something like Python's PEP: you need a proposal to convince your reviewer that you have put…

Requiring permission to do work is the enemy of progress and engineering dignity. It creates a presumption of incompetence and an atmosphere of low trust that punishes people who want to push the envelope of what's possible. Google's design document culture is bad. Google has succeeded in spite of it. In my experience, having worked at many large tech companies, design documents obfuscate, not enlighten. They become…

>Requiring permission to do work is the enemy of progress and engineering dignity. It creates a presumption of incompetence and an atmosphere of low trust that punishes people who want to push the envelope of what's possible.

Its not a permission to do work, its permission to merge the results of the work to master. Those are different.

>Google's design document culture is bad.

Then why do we have JEPs, PEPs, and rfcs in perhaps every other major project out there?

Re: Why I close pull requests

#57

Post by skj »

fdsfsaa wrote: post #47
yegle wrote: post #13

At Google, if you want to implement new features (or large refactoring), you'll need to write a design doc. In which, you should answer questions your reviewers might ask (common questions like: why do you want to do this, what are the alternatives, how components interactive with each other before/after your change). This is something like Python's PEP: you need a proposal to convince your reviewer that you have put…

Requiring permission to do work is the enemy of progress and engineering dignity. It creates a presumption of incompetence and an atmosphere of low trust that punishes people who want to push the envelope of what's possible. Google's design document culture is bad. Google has succeeded in spite of it. In my experience, having worked at many large tech companies, design documents obfuscate, not enlighten. They become…

We write design docs at Google to communicate ideas with each other. They're useful for promo committees because effective communication between engineers is something that is prerequisite for effective engineering.

Of course a full design doc is not needed for every change. Many changes are small and straightforward. Only big things, where the team needs to discuss and understand options. Or bigger things, where directors etc need to sign off (not really design docs anymore, but same basic thing).

The fact is that, on average, design doc+code takes less time than code without design (that is, without communication). Again, only for certain kinds of changes. Things go faster because problems are found, approaches are adjusted, or unmotivated features are axed.

Re: Why I close pull requests

#58

Post by fdsfsaa »

zardeh wrote: post #56
fdsfsaa wrote: post #47

Earlier quoted context omitted.

Requiring permission to do work is the enemy of progress and engineering dignity. It creates a presumption of incompetence and an atmosphere of low trust that punishes people who want to push the envelope of what's possible. Google's design document culture is bad. Google has succeeded in spite of it. In my experience, having worked at many large tech companies, design documents obfuscate, not enlighten. They become…

>Requiring permission to do work is the enemy of progress and engineering dignity. It creates a presumption of incompetence and an atmosphere of low trust that punishes people who want to push the envelope of what's possible. Its not a permission to do work, its permission to merge the results of the work to master. Those are different. >Google's design document culture is bad. Then why do we have JEPs, PEPs, and rfc…

Counterexample: the Linux kernel.

Re: Why I close pull requests

#59

Post by fdsfsaa »

skj wrote: post #57
fdsfsaa wrote: post #47

Earlier quoted context omitted.

Requiring permission to do work is the enemy of progress and engineering dignity. It creates a presumption of incompetence and an atmosphere of low trust that punishes people who want to push the envelope of what's possible. Google's design document culture is bad. Google has succeeded in spite of it. In my experience, having worked at many large tech companies, design documents obfuscate, not enlighten. They become…

We write design docs at Google to communicate ideas with each other. They're useful for promo committees because effective communication between engineers is something that is prerequisite for effective engineering. Of course a full design doc is not needed for every change. Many changes are small and straightforward. Only big things, where the team needs to discuss and understand options. Or bigger things, where dir…

> We write design docs at Google to communicate ideas with each other.

I have no problem with individual developers choosing to circulate documents in order to solicit feedback. My objection is to rigid processes that force engineers to write documents.

Mandatory design documents for "communication" invariably morph into checklists of required signoffs from people who have little incentive to say "yes". In this way, a culture of design documents breeds a culture of extreme risk avoidance.

It's a tragedy, really. Through numerous small steps, each apparently reasonable, a nimble organization becomes an ossified nightmare in which it takes six months to add a checkbox.

> The fact is that, on average, design doc+code takes less time than code without design

Prove it. Provide evidence. In my experience, your claim is not the case for most changes in most projects. For the changes where design documents facilitate development, my experience is that developers will choose to circulate documents even when not required to do so.

> Unmotivated features are axed.

One developer's "unmotivated feature" is another developer's essential use case.

Re: Why I close pull requests

#60

Post by daurnimator »

mikepurvis wrote: post #37
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 PR…

> resolve merge/rebase conflicts

This was added to github rather recently

Post reply on HN