Live data from Hacker News

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

blog.ploeh.dk

31–40 of 101 posts

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

#31
> "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 system is not going to fix that for you."

Man, I don't trust myself to be perfect. I trust myself to be careful but no amount of care makes me infallible. I make mistakes. And if we can catch my mistakes early by getting a second set of eyes on them, they're less painful for everyone to fix. When someone spends their valuable time catching my mistakes, they're doing me a favor.

Distrust might be part of the origin of pull requests, but that doesn't have to be the reason why your team uses pull requests. It can be about catching each others mistakes to learn, create a better product, and get better rewards. The tool is yours to use how you see fit--don't let ego prevent you from making it useful.

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

#32
post #16

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…

> 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.

A possible reason is that it won't happen in git, simply because separate branches aren't sufficiently painful to motivate sharing that single hot mess HEAD. I used to work in a team where it felt like I was the only person who ever thought about these things and it was quite impressive how the switch from SVN to git completely flipped the path of (supposedly) least resistance: from separate branches only as a last ditch option for the most desperate situations to happy unbounded parallelism right until the (supposed) delivery day.

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

#33
A pull request is when one maintainer asks another to merge branches.

If you’re interpreting this through the lens of a single main/master/trunk and multiple branches, then like both Farley and the author, you’re trying to interpret a foreign culture (distributed version control) through a parochial lens (single trunk-multiple branch).

The DVCS world is one of many sources of truth. For example, in the kernel community, Red Hat, Google, Debian, Android, etc. all have their own branches. Linus has a particularly popular branch. None of them are the main branch.

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

#34
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…

As far back as the year 2001, way before Git existed, a small startup I worked for used mandatory code review for all commits. You couldn't just upload whatever garbage and call it a day, it had to successfully compile and be reviewed by a randomly selected peer. These days Pull Requests are used to enable the same workflow.

Was the startup successful? :)

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

#35
I think we have GH set up so we can make direct pushes to even main, we just agreed to do PRs because frankly I don’t even trust myself to do everything right and optimal. PRs are nice for reviews, but also for testing and discussion, sometimes just to share something you are not sure if it is the best. It’s just a way to present changes to people just trust (or don’t) and to have a place for discussion.

That’s how we treat PRs anyway. Occasionally I or a colleague indeed accepts their own PR (or use direct pushing) if it’s really minor (think a doc string) and need to get something out. So PRs are not just for envs without trust.

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

#36

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"?

It's a "pull request" because you're asking someone to pull a commit from your branch/repo into theirs. You're quite literally making a request.

This actual change could be anything. You could just as well provide them as a patch they could apply by hand. The only formal aspects of the process, e.g. reviews and tests, are organizational. As an organization the acceptance of a pull request doesn't need a bunch of reviews and tests associated.

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

#37
post #16

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…

> 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.

The big difference between SVN and Git is that SVN is centralized (a single linear history is enforced at all times for everyone) and Git is distributed (each user has its own local history).

Both models have advantages and disadvantages, but for many people working on the same branch the centralized model is arguably better.

(in the end, both Github and Gitlab workflows mainly try to put more 'centralization' back into git)

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

#38
It frustrates me the one size fits all approach often taken to software development best practices.

If no one is to review the code, then all code is either written by pairing/mobbing, or else it is the product of one persons thinking, blindspots, biases and all. It's great if you work in a team that pairs in everything, does trunk based development etc; that doesn't make it suitable for every team.

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

#39
It seems like we are reaching the same conclusions as Dave Farley on our development team. We have pivoted to just let everyone merge in their stuff and do "reviews" retroactively when we stumble upon code not up to the standard we set.

The reasoning behind this is exactly that we trust individuals on the team to merge. and because reviewing in the traditional sense seems to be a formalisation of distrust: Something you do when you don't trust your peers to implement and put in production properly tested code.

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

#40
With all the precautions the author takes, he ends up with a weird take:

> If you take away the appeal to trust, though, there isn't much left of the argument. What remains is essentially: Pull requests were invented to solve a particular problem in open-source development. Internal software development is not open source. Pull requests are bad for internal software development.

The specific point he tries to reword exists to explain that not everyone needs as much trust than open-source, and, therefore, that not having PR isn't a fatal flaw outside of open-source. The people who use it do so within a discourse along with other points explaining what they gain from forgoing PRs (usually, better continuous integration).

I don't buy the whole discourse about not using PRs, but I'm also not sold on the idea of dismantling a coherent discourse into separate talking points and demanding that they should stand separately. I'm also not a fan of rewording someone else's point and slipping a big non-sequitur in that rewording.

Post reply on HN