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

Are pull requests bad because they originate from open-source development?

blog.ploeh.dk

Post reply on HN
Print view View original

11–20 of 101 posts

Re: Are pull requests bad because they originate from open-source development?

#11

Post by mpweiher »

coldtea wrote: post #2

> "Pull requests were invented to gatekeep access to open-source projects. In open source, it's very common that not everyone is given free access to changing the code, so contributors will issue a pull request so that a trusted person can then approve the change. "I think this is really bad way to organise a development team. "If you can't trust your team mates to make changes carefully, then your version control sy…

> This guy ... has never heard of "trust but verify"

I think he has, and actually knows where it comes from and what it means.

"Trust but verify" is a Russian proverb that was used to describe the hoped-for and treaty-mediated relationship between the Soviet Union and the United States during the Reagan-Gorbachev era.

So arch-enemies of a Cold War that are pointing world-ending nuclear arsenals at each other and slowly coming to realise that maybe it would be better to limit those by negotiated treaty.

If that's a good description of the relationships in your team, then I think David Farley wasn't just right, but actually being very diplomatic ;-)

Re: Are pull requests bad because they originate from open-source development?

#12

Post by lone-commenter »

Relevant paragraph IMO:

> First, it includes an appeal to trust, which is a line of reasoning with which I don't agree. You can't trust your colleagues, just like you can't trust yourself. A code review serves more purposes than keeping malicious actors out of the code base. It also helps catch mistakes, security issues, or misunderstandings. It can also improve shared understanding of common goals and standards. Yes, this is also possible with other means, such as pair or ensemble programming, but from that, it doesn't follow that code reviews can't do that. They can. I've lived that dream.

I think that the other counter-argument discussed in the article can't confute Farley because, contrary to the author's stated intentions, it is in fact a straw man. The author focuses on the benefits of "asynchronous" workflows over "synchronous" ones: i.e., in his words, reviewing pull requests is easier (for an introvert like himself, at least) than dealing with the social stress involved in pair/ensemble programming.

Re: Are pull requests bad because they originate from open-source development?

#13

Post by lukeramsden »

flohofwoe wrote: post #9
v3ss0n wrote: post #5

[flagged]

Up to about 10 years ago I used to work on projects where up to 100 people (of those about 20 coders, the rest artists and designers) committed directly into the main branch without a formal review process, and it was ok (this was with SVN though). Code review happened informally "after the fact", usually as the first thing in the morning when updating (each person simply looked through the changes of other people in…

Works absolutely fine with git, you just have to take the time to keep the pre-commit checks reasonably quick

Re: Are pull requests bad because they originate from open-source development?

#15

Post by flohofwoe »

lukeramsden wrote: post #13
flohofwoe wrote: post #9

Earlier quoted context omitted.

Up to about 10 years ago I used to work on projects where up to 100 people (of those about 20 coders, the rest artists and designers) committed directly into the main branch without a formal review process, and it was ok (this was with SVN though). Code review happened informally "after the fact", usually as the first thing in the morning when updating (each person simply looked through the changes of other people in…

Works absolutely fine with git, you just have to take the time to keep the pre-commit checks reasonably quick

IMHO what makes it harder in git (for many people committing into the same branch) is that each team member has its own local history which needs to be synchronised via push and fetch (which quickly gets out of control for 'non-technical' team members). This separate step doesn't exist in centralized version control systems like SVN where everybody is always on the same timeline.

Working exclusively on branches and then merging into a common main branch pretty much fixes this problem though (that's why the PR workflow make a lot more sense in git than svn).

Re: Are pull requests bad because they originate from open-source development?

#16

Post by fuzzy2 »

flohofwoe wrote: post #9
v3ss0n wrote: post #5

[flagged]

Up to about 10 years ago I used to work on projects where up to 100 people (of those about 20 coders, the rest artists and designers) committed directly into the main branch without a formal review process, and it was ok (this was with SVN though). Code review happened informally "after the fact", usually as the first thing in the morning when updating (each person simply looked through the changes of other people in…

> I cannot imagine how this scenario could work with git though.

I cannot image how this scenario could not work with Git†. Maybe I’m missing something important about Subversion, but it’s also just plain old version control. Nothing fancy like Darcs.

†: Granted, there is a (theoretical) point where the frequency of pushes becomes so high you can no longer reasonably work on a single branch.

Re: Are pull requests bad because they originate from open-source development?

#17

Post by someweirdperson »

Calling pull requests "pull request" when it is a job to create a change is what's wrong. The author isn't actually requesting anything.

But what else could be a nice short term for "collection of changes with technically enforced reviews and tests"?

Re: Are pull requests bad because they originate from open-source development?

#18

Post by rob74 »

mpweiher wrote: post #11
coldtea wrote: post #2

> "Pull requests were invented to gatekeep access to open-source projects. In open source, it's very common that not everyone is given free access to changing the code, so contributors will issue a pull request so that a trusted person can then approve the change. "I think this is really bad way to organise a development team. "If you can't trust your team mates to make changes carefully, then your version control sy…

> This guy ... has never heard of "trust but verify" I think he has, and actually knows where it comes from and what it means. "Trust but verify" is a Russian proverb that was used to describe the hoped-for and treaty-mediated relationship between the Soviet Union and the United States during the Reagan-Gorbachev era. So arch-enemies of a Cold War that are pointing world-ending nuclear arsenals at each other and slow…

You can hopefully trust your colleagues to make a best-effort attempt to fulfill the requirements they are given and e.g. not intentionally introduce bugs or security issues, but everyone makes mistakes, so your software development workflow should account for this - and code review catches at least some of these mistakes.

Re: Are pull requests bad because they originate from open-source development?

#19

Post by guntherhermann »

coldtea wrote: post #2

> "Pull requests were invented to gatekeep access to open-source projects. In open source, it's very common that not everyone is given free access to changing the code, so contributors will issue a pull request so that a trusted person can then approve the change. "I think this is really bad way to organise a development team. "If you can't trust your team mates to make changes carefully, then your version control sy…

"Trust but verify" is a nonsense statement. If you trust, you do not need to verify, and vice versa.

Re: Are pull requests bad because they originate from open-source development?

#20

Post by whatshisface »

mpweiher wrote: post #11
coldtea wrote: post #2

> "Pull requests were invented to gatekeep access to open-source projects. In open source, it's very common that not everyone is given free access to changing the code, so contributors will issue a pull request so that a trusted person can then approve the change. "I think this is really bad way to organise a development team. "If you can't trust your team mates to make changes carefully, then your version control sy…

> This guy ... has never heard of "trust but verify" I think he has, and actually knows where it comes from and what it means. "Trust but verify" is a Russian proverb that was used to describe the hoped-for and treaty-mediated relationship between the Soviet Union and the United States during the Reagan-Gorbachev era. So arch-enemies of a Cold War that are pointing world-ending nuclear arsenals at each other and slow…

Here are some examples of trust-but-verify relationships at work:

- You are allowed to expense things while traveling, but someone will look at what you put on the company card afterwards.

- They don't wait on your background check before moving ahead with interviews.

- Someone really should look at your code, at some point, before it is released.

Post reply on HN