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

81–90 of 188 posts

Re: Why I close pull requests

#81

Post by zardeh »

unixhero wrote: post #77
zardeh wrote: post #69

Earlier quoted context omitted.

Which leads to problems: see systemd. Also, to be clear, Linux is relatively small compared to Google or Microsoft, or indeed many corporations codebases. Someone could conceivably read the entire Linux kernel codebase. That's not true for BigCorp.

I beg to differ. https://youtu.be/yVpbFMhOAwE

Right, a single book has on the order of 4-500 pages, longer ones have more, but we'll take the average, and an average book has....30 lines of text per page, so 13500 lines per book. That makes the kernel ~1000 books, which is a lot of books, but avid readers do read 50+ books per year (my father probably does close to double this). That makes reading the entire source absolutely possible, in the order of 10s of years, which is a long time, but then, the kernel has been around for what, 25 now? So there are a number of maintainers who have been around long enough to have read through the entire kernel.

Compare that to google, where[1] there are almost as many unique source files as the kernel has lines (though to be fair, many are autogenerated).

[1]: http://cacm.acm.org/magazines/2016/7/204032-why-google-store...

Re: Why I close pull requests

#82

Post by akkartik »

mikepurvis wrote: post #79
akkartik wrote: post #66

Earlier quoted context omitted.

Have you considered just constantly rebasing as you pull? This works well for private forks, but it may also be doable for public forks if you explain what's going on in the Readme. Just an idea. I know it goes against everything we learn about Git, but perhaps it's not so bad in this particular situation.

Yeah, I mean that's basically what you do, but it becomes a huge pain if you're making more than one contribution upstream. You feature-branch-1, feature-branch-2, and then the upstream master with those two branches merged into it. When you update either one of the two PRs, you need to rewind the upstream master and reapply the two merges onto it. Maybe that doesn't sound so bad, but it feels super awkward to me.

Ah, I see. Makes more sense when I reread it now. I'm just not juggling multiple patches at a time like this, but it's a valid workflow.

Re: Why I close pull requests

#83

Post by sanxiyn »

mikeash wrote: post #44
ageofwant wrote: post #41

Earlier quoted context omitted.

I sometimes use the fork button just to get a copy I may or may not play with over the weekend.

How does that help? Are you just using the presence of the fork in your account as a sort of bookmark?

I use stars for this, but I guess one could use forks as kind of "super stars".

Re: Why I close pull requests

#84

Post by rpedela »

greglindahl wrote: post #39
Nadya wrote: post #25

Earlier quoted context omitted.

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.

I think it depends a lot on context. If I am looking to contribute for the sole purpose of improving the OSS project, then I follow your method. If I am using an OSS project in a larger commercial project and I need a bugfix or feature now, I just build it. If I think it may be useful to the OSS project, then I will contribute back with the understanding that it may not be merged.

Re: Why I close pull requests

#85

Post by scottlamb »

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…

> A culture that requires permissions and signoffs before work can begin is a culture that leaves products stagnant for years.

I don't see such a culture. I often create one or more prototypes as part of my design. One of those might become the final result, or I might throw away everything. As long as that's understood, all is well.

The way I think about it is this: don't do work you aren't willing to throw away until earlier steps have been reviewed. How much work you're willing to throw away is a personal preference. Your design reviewer(s) might say "did you consider this other way that has these advantages?" You shouldn't reply with "No, and I've invested too much time to consider other approaches now. Stop holding me up and lgtm already." No one wants to work with someone like that. Your argument should be based on what's best. What's already done should only be considered if neither approach is (believed to be) significantly better.

Re: Why I close pull requests

#86

Post by user5994461 »

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

Wow. I feel terribly offended as an engineer.

Could we not confuse "engineering" with "pushing random changes at any times that may not even pass the tests by any bro-ninja that just felt like it".

The poster has clearly never written or maintained any critical software.

Re: Why I close pull requests

#87

Post by user5994461 »

fdsfsaa wrote: post #55
stinkytaco wrote: post #50

Earlier quoted context omitted.

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

> When you ship every week, you can easily undo mistakes, and you're better off erring toward iteration.

Or so they thought: http://pythonsweetness.tumblr.com/post/64740079543/how-to-lo...

Re: Why I close pull requests

#88

Post by dismantlethesun »

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…

> In my experience, having worked at many large tech companies, design documents obfuscate, not enlighten. They become increasingly out-of-date as the code evolves, creating anti-documentation that makes it take longer to understand code. Yes, yes, people should update design documents as the code evolves. Everyone knows that in practice, nobody updates old design documents.

My experience has been the reverse, precisely because as you said.... no one updates old design documents.

A piece of code with a design document at least has a historical record of what the original aims of the project were, and a written rationale for why they took certain approaches.

Often you'll find a piece of code with a seemingly inane architecture and wonder "why is this so inane? were the the developers on drugs?". By reading the design document, you find out that sadly no the water fountains were not spiked with LSD in the 70s, but rather they were working around the performance characteristics of hardware that no longer exists and thus these baked in assumptions had reason and merit.

Understanding the original why often illuminates the entire architecture, even if undergone a lot of changes because the original skeleton still remains.

I sort of look at it as Code Archeology, or maybe literary deconstruction as applies to code.

Re: Why I close pull requests

#89

Post by dismantlethesun »

user5994461 wrote: post #86
stinkytaco wrote: post #50

Earlier quoted context omitted.

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 Wow. I feel terribly offended as an engineer. Could we not confuse "engineering" with "pushing random changes at any times that may not even pass the tests by any bro-ninja that just felt like it". The poster has clearly never written or maintained any critical software.

I thought design documents and reporting were mandatory for 'engineering'. As is things like ethics, and organizational standards, and testability.

Move fast and break something is the domain of hacking.

Re: Why I close pull requests

#90

Post by dismantlethesun »

fdsfsaa wrote: post #55
stinkytaco wrote: post #50

Earlier quoted context omitted.

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

> You shouldn't hire people who don't give enough of a shit to take the big picture into account.

Even if you care, you can't know the entire story. I work for a small company, tiny compared to Google, but often we run into someone proposing a change that backtracks on a strategy decided 2 years ago. Luckily it was encoded in a design document or else, how would anyone new find out about it?

New people want to know the big picture, but the best way to do that is to write about your decisions as you are making them, and give them some sort of searchable record.

Personally, I love Github because while you don't have formal design docs---you do have a history of the entire argument of why a feature should be implemented, followed up with a history of all the breaking changes caused by it, and the final reversion. It's great to plunge into a codebase, and see how did we get there, before deciding to propose something.

Have you ever been on a team, and proposed something only to hear "yes we tried that, it failed for X,Y,Z reasons... but no we never noted down starting this 6 month initiative down anywhere except my head".

Post reply on HN