6 ms·

This might work for slow moving teams with a few contributors, but I can't imagine using this in the way I've seen github used on projects with many contributor

This might work for slow moving teams with a few contributors, but I can't imagine using this in the way I've seen github used on projects with many contributors... Email just doesn't scale as well

hyperpape 8y ago
Since he mentions Linux as the primary example of a project that uses email, I think this particular criticism needs some refinement.
- Areading314 8y ago
  I'm sure plenty of Linux maintainers would much prefer using github if they could...
  - hyperpape 8y ago
    Maybe! I'm also a skeptic—see my other comment. But just saying "it can't work" is untenable.
  - Areading314 8y ago
    Here is an interesting post about the Linux project and why they don't use GitHub https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kerne...
- craftyguy 8y ago
  Mesa is another large project using email for patch submission and review.
- kccqzy 8y ago
  > Using email for git scales extremely well. The canonical project, of course, is the Linux kernel. A change is made to the Linux kernel an average of 7 times per hour, constantly. Tell that to any big team in a big company or even a medium-sized company using a monorepo. The Linux project has a very high bar for entry and it's not an example of a busy repo.
  - Sir_Cmpwn 8y ago
    Linux upstream gets 7 commits per hour, but the Linux project is divided into subsystems which are run like independent projects that periodically push their work upstream. The volume of activity that Linux receives is very high. Can you back up your statements with evidence? I have no reason to believe that email wouldn't work in a large monorepo-like setting. The less-than-10-in-total companies which have crazy Google-tier monorepos may run into issues with this (honestly, though, I doubt it), but they are not the norm.
- progval 8y ago
  Linux is kind of special, only experienced developers contribute to it because working on a kernel is hard. Most projects are more accessible to beginners, and GitHub makes it much easier for them to do their first contribution to an open source project.
wskinner 8y ago
Can you explain why email doesn’t scale? Do you mean the protocols, the clients, the servers, or something else?
- Areading314 8y ago
  Having to sort through messages individually, not being able to browse code, no convenient links, no formatting, no branch visualizations, release notes being easily accessible, having to set up a bunch of fragile text based filters. It's just obviously a worse choice
  - rmurri 8y ago
    I don't think the intent is to do code review from email. The idea would be to send the merge request through email, which is then imported into your local git as a branch. Then you're able to do review/analysis/etc with whichever git tooling you prefer.
  - GuyPostington 8y ago
    Have you tried it to see if it's actually as bad as you think?
    - s73v3r_ 8y ago
      I guess the question would be, what compelling reason would there be to do so? To me, the article's advantages are kinda meh, and I much prefer the tools provided in code review packages.
  - sedachv 8y ago
    > Having to sort through messages individually Your email reader is supposed to help you read and reply to message threads. > not being able to browse code You browse code by doing a git clone/checkout, and then using your regular programming tools. > no convenient links Your email client should help you navigate and search message threads. Here is one of many that helps you do this: http://www.djcbsoftware.nl/code/mu/mu4e.html http://www.djcbsoftware.nl/code/mu/mu4e.html > no formatting This is what you editor is supposed to do. > no branch visualizations This is what tools like magit are supposed to do: https://magit.vc/ https://magit.vc/ > release notes being easily accessible They go in a text file in the repository. You open the text file with your editor. Your editor should also help you write release notes: https://www.gnu.org/software/emacs/manual/html_node/emacs/Change-Log-Commands.html https://www.gnu.org/software/emacs/manual/html_node/emacs/Ch... > having to set up a bunch of fragile text based filters. Why? I see arguments like yours about email and git a lot. Why do you think people disagree with you? You have to pay attention to what you are really saying. You are not listing advantages of web-based git interfaces. You are listing "disadvantages" of existing tools. And all of the "disadvantages" you list are really areas where you do not understand how to use Unix programming tools effectively. Getting off of webmail and onto a good text-based email client is one of the best things you can do as a computer user.
toopsss 8y ago
If you knew one whit about what you’re talking about you’d feel pretty silly about this comment.
- dang 8y ago
  You may be right, but this comment breaks the site guidelines by being uncivil and unsubstantive. That's not a good way to be right on HN. Better is to politely provide necessary corrective information, so then the rest of us can learn something. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

This might work for slow moving teams with a few contributors, but I can't imagine using this in the way I've seen github used on projects with many contributors... Email just doesn't scale as well

hyperpape 8y ago

Since he mentions Linux as the primary example of a project that uses email, I think this particular criticism needs some refinement.

Areading314 8y ago
I'm sure plenty of Linux maintainers would much prefer using github if they could...
- hyperpape 8y ago
  Maybe! I'm also a skeptic—see my other comment. But just saying "it can't work" is untenable.
- Areading314 8y ago
  Here is an interesting post about the Linux project and why they don't use GitHub https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kerne...
craftyguy 8y ago
Mesa is another large project using email for patch submission and review.
kccqzy 8y ago
> Using email for git scales extremely well. The canonical project, of course, is the Linux kernel. A change is made to the Linux kernel an average of 7 times per hour, constantly. Tell that to any big team in a big company or even a medium-sized company using a monorepo. The Linux project has a very high bar for entry and it's not an example of a busy repo.
- Sir_Cmpwn 8y ago
  Linux upstream gets 7 commits per hour, but the Linux project is divided into subsystems which are run like independent projects that periodically push their work upstream. The volume of activity that Linux receives is very high. Can you back up your statements with evidence? I have no reason to believe that email wouldn't work in a large monorepo-like setting. The less-than-10-in-total companies which have crazy Google-tier monorepos may run into issues with this (honestly, though, I doubt it), but they are not the norm.
progval 8y ago
Linux is kind of special, only experienced developers contribute to it because working on a kernel is hard. Most projects are more accessible to beginners, and GitHub makes it much easier for them to do their first contribution to an open source project.

wskinner 8y ago

Can you explain why email doesn’t scale? Do you mean the protocols, the clients, the servers, or something else?

Areading314 8y ago
Having to sort through messages individually, not being able to browse code, no convenient links, no formatting, no branch visualizations, release notes being easily accessible, having to set up a bunch of fragile text based filters. It's just obviously a worse choice
- rmurri 8y ago
  I don't think the intent is to do code review from email. The idea would be to send the merge request through email, which is then imported into your local git as a branch. Then you're able to do review/analysis/etc with whichever git tooling you prefer.
- GuyPostington 8y ago
  Have you tried it to see if it's actually as bad as you think?
  - s73v3r_ 8y ago
    I guess the question would be, what compelling reason would there be to do so? To me, the article's advantages are kinda meh, and I much prefer the tools provided in code review packages.
- sedachv 8y ago
  > Having to sort through messages individually Your email reader is supposed to help you read and reply to message threads. > not being able to browse code You browse code by doing a git clone/checkout, and then using your regular programming tools. > no convenient links Your email client should help you navigate and search message threads. Here is one of many that helps you do this: http://www.djcbsoftware.nl/code/mu/mu4e.html http://www.djcbsoftware.nl/code/mu/mu4e.html > no formatting This is what you editor is supposed to do. > no branch visualizations This is what tools like magit are supposed to do: https://magit.vc/ https://magit.vc/ > release notes being easily accessible They go in a text file in the repository. You open the text file with your editor. Your editor should also help you write release notes: https://www.gnu.org/software/emacs/manual/html_node/emacs/Change-Log-Commands.html https://www.gnu.org/software/emacs/manual/html_node/emacs/Ch... > having to set up a bunch of fragile text based filters. Why? I see arguments like yours about email and git a lot. Why do you think people disagree with you? You have to pay attention to what you are really saying. You are not listing advantages of web-based git interfaces. You are listing "disadvantages" of existing tools. And all of the "disadvantages" you list are really areas where you do not understand how to use Unix programming tools effectively. Getting off of webmail and onto a good text-based email client is one of the best things you can do as a computer user.

toopsss 8y ago

If you knew one whit about what you’re talking about you’d feel pretty silly about this comment.

dang 8y ago
You may be right, but this comment breaks the site guidelines by being uncivil and unsubstantive. That's not a good way to be right on HN. Better is to politely provide necessary corrective information, so then the rest of us can learn something. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html