6 ms·

Web is far more usable The big difference here is that you seem to hate web for what amounts to meaningless ideology, whereas people like me hate email for ver

Web is far more usable The big difference here is that you seem to hate web for what amounts to meaningless ideology, whereas people like me hate email for very practical reasons.

ycmbntrthrwaway 10y ago
I don't hate any and use both every day.
jcranmer 10y ago
This is how you submit a patch to an email list: 1. Clone the repository locally 2. Make the fix 3. Run $VCS email --to=<list> 4. Done! This is how you submit a patch via github: 1. Clone the repository locally 2. Make the fix 3. Fork the repository on GitHub 4. Push your changes to your GitHub fork 5. Go through several screens to make a pull request on GitHub. (This is assuming you have a GitHub account. If you don't have one, or if you don't know its UI well, insert several more steps in the middle.) For a casual contributor, sending a patch via email is quite easier than doing it in the web. There are of course downsides to both approaches, but please don't pretend that there are no reasonable objections to web UIs.
- mememachine 10y ago
  Thats actually a good point
- ufmace 10y ago
  Exactly how does it know how to send email from the command line? I'm using gmail. Am I supposed to figure out how to configure gmail for SMTP, put the server and creds in a config file somewhere, and hope I don't bump up against any ISP firewalls or Google security tricks? Or see Manishearth's comment above. Meanwhile, you may have to create a Github account and fork the repo for PRs, but I don't see any way for that to not be trivial. Yeah, you gotta know Git, but at least Github has nice easy buttons to guide you through doing things.
  - carussell 10y ago
    > Meanwhile, you may have to create a Github account and fork the repo for PRs, but I don't see any way for that to not be trivial It's been said. You do it with a service built upon the traditional currency of open source: patches. GitHub-style pull requests are not an intrinsic requirement even for the kind of shiny web UI that GitHub wanted to build. It was, however, an important part of GitHub's lock-out strategy. If you build your startup so that the way that person B has to get their changes to person A is through a pull request, then you can make sure that not only is person A active in the market for Git hosting, but person B is, too. They'll need to throw their changes up on some Git hosting service, because it has to live somewhere. And if your startup happens to be a Git hosting service, that's good for you. And, hey! since it's a pull request, you can do more than strongly suggest that person B hosts their stuff with you, you can force it, by making it impossible for the pull request to come from off-site. You can't do that kind of underhanded "growth hacking" if you allow contributors to submit patches, because while pull requests are indirect, patches are self-contained. They are a unit of change. (I've referred to this in the past as using a strategy of dark patterns inspired by social networks.) I want to emphasize: "patches vs pull requests" is one matter, and "email vs web UI" is an entirely different matter. It's a 2×2 matrix, not a dichotomy. But this conversation has (annoyingly) run on as if it is "patches (which must be done through email) vs pull requests (which are done through point and click)". There's nothing that precludes GitHub from having built a web UI where today's "pull request" button ended with a "submit patch" button in its place. Nothing. > I don't see any way for that to not be trivial Yes, this is clear every time the conversation comes up. Something has happened wrt GitHub that causes people to a) forget how things looked before GitHub, b) have extreme difficulty imagining that things could work any other way—even when the other way is more straightforward and less convoluted than the way GitHub actually works. It's kind of nuts.
    - mememachine 10y ago
      It does leave a bad taste in my mouth that github is required, and they could easily do something about it. If they were open about it i probably wouldnt care, but this seems deceptive.
  - 10y ago
- y2kenny 10y ago
  This is how you submit a patch to Gerrit: 1. Clone the repository locally 2. Make the fix 3. Run 'git push origin HEAD:refs/for/master'. Done (without needing to setup SMTP.)
  - kiallmacinnes 10y ago
    Better yet, install `git-review`, a project that came out of OpenStack's use of Gerrit. 1. Clone the repository locally 2. Make the fix 3. Run 'git review'. Done (without needing to remember that annoying refs/for/foo syntax.)
  - deleted 10y ago
    [deleted]
- ajdlinux 10y ago
  A casual contributor is more likely to already have a GitHub account than to have git-send-email configured correctly.
  - mi100hael 10y ago
    Most maintainers aren't looking for "casual contributors." It's a huge pain in the ass to have someone open a half-baked PR and then never respond to feedback or support questions.
- justinclift 10y ago
  Just to point out, for drive by commits (eg typo fixes, etc), GitHub is super simple: 1. Go to the file in GitHub you want to change 2. Click the "Edit" icon 3. Click the "Create Pull Request" button There's no need to create a fork and branch manually any more, GitHub does it automatically behind the scenes. It's a useful optimisation. :)
  - tracker1 10y ago
    Though I really wish that GH would cleanup the fork on your profile when the PR is closed, or offer an easy button to nuke those... Minor niggle.
    - justinclift 10y ago
      Yep, that would be useful. :)
- tracker1 10y ago
  Depends on the patch... if it's a typo fix on a readme, or updated url in a documentation file... you click the edit button on github, save, then create PR button after... easy peasy. It really depends on what you are trying to do in terms of what the process is.. generally, if you aren't a contrib, you will fork, and work from a branch on your locally cloned fork.. you push to that branch, and then create a PR upstream. You may create a local ref to the upstream branch in order to facilitate updates to your fork, and for handling squash/rebase scenarios. A lot of this is simply git... the "fork" on github creates a github hosted remote copy of the upstream project. The PR is a chance to review upstream patching. Yes, this can be done via email... but you can also do a lot of things in email, that email is a bad user experience for.
- lmm 10y ago
  Compare like with like, don't count screens one way and count preconfigured command lines the other way. If you have $VCS set up nicely, it's a one-liner there. If you have GitHub set up nicely, it's a one-liner in GitHub too. If you don't have $VCS set up, it's a large number of obscure manpages. If you don't have GitHub set up, it's a couple of clicks in a friendly UI (and actually far fewer clicks than you list, these days).
zAy0LfpBZLC8mAC 10y ago
I hate web because it provides a user interface instead of a programming interface. If I don't like the existing user interface to a standardized machine-readable protocol/format, I can write my own user interface for my own needs, as can anyone else, which has two big advantages: People with different needs can have user interfaces that match their respective needs, even while working on the same project, and that leads to easier innovation (when people share their respective solutions). Now, github currently provides the low-barrier solution that seems to be good enough for many people, which is why the development of tools for email-based workflows is stagnating, instead building more lock-in for github, and preventing any serious improvement in workflows. So, your hate for email is for practical reasons, but those practical reasons are not inherent properties of email, but rather the result of github trying to capture the market for later exploitation, and you are happy to help them for the momentary convenience, while probably not realizing how much potential convenience you are missing out on as a side effect.
- notriddle 10y ago
  > I hate web because it provides a user interface instead of a programming interface. https://api.github.com/ https://api.github.com/
  - zAy0LfpBZLC8mAC 10y ago
    Which is mostly missing the point. First of all, github is not the web, and much of the web does not have an API (and I don't have a clue how good the github API is). But more importantly, even if they have an API: Is there any legally binding committment on their part that that API will be a reliable basis for me to build on for the next 20 years or so, assuming they still exist then? Won't they change it as it suits their needs, in particular their business needs? A "programming interface" that I can't rely on in the long run is still kindof a user interface, as I have to bother with it whenever it changes. It's a real programming interface only if I can build an abstraction on top of it and essentially forget the layers beneath.

Web is far more usable The big difference here is that you seem to hate web for what amounts to meaningless ideology, whereas people like me hate email for very practical reasons.

ycmbntrthrwaway 10y ago

I don't hate any and use both every day.

jcranmer 10y ago

This is how you submit a patch to an email list: 1. Clone the repository locally 2. Make the fix 3. Run $VCS email --to=<list> 4. Done! This is how you submit a patch via github: 1. Clone the repository locally 2. Make the fix 3. Fork the repository on GitHub 4. Push your changes to your GitHub fork 5. Go through several screens to make a pull request on GitHub. (This is assuming you have a GitHub account. If you don't have one, or if you don't know its UI well, insert several more steps in the middle.) For a casual contributor, sending a patch via email is quite easier than doing it in the web. There are of course downsides to both approaches, but please don't pretend that there are no reasonable objections to web UIs.

mememachine 10y ago
Thats actually a good point
ufmace 10y ago
Exactly how does it know how to send email from the command line? I'm using gmail. Am I supposed to figure out how to configure gmail for SMTP, put the server and creds in a config file somewhere, and hope I don't bump up against any ISP firewalls or Google security tricks? Or see Manishearth's comment above. Meanwhile, you may have to create a Github account and fork the repo for PRs, but I don't see any way for that to not be trivial. Yeah, you gotta know Git, but at least Github has nice easy buttons to guide you through doing things.
- carussell 10y ago
  > Meanwhile, you may have to create a Github account and fork the repo for PRs, but I don't see any way for that to not be trivial It's been said. You do it with a service built upon the traditional currency of open source: patches. GitHub-style pull requests are not an intrinsic requirement even for the kind of shiny web UI that GitHub wanted to build. It was, however, an important part of GitHub's lock-out strategy. If you build your startup so that the way that person B has to get their changes to person A is through a pull request, then you can make sure that not only is person A active in the market for Git hosting, but person B is, too. They'll need to throw their changes up on some Git hosting service, because it has to live somewhere. And if your startup happens to be a Git hosting service, that's good for you. And, hey! since it's a pull request, you can do more than strongly suggest that person B hosts their stuff with you, you can force it, by making it impossible for the pull request to come from off-site. You can't do that kind of underhanded "growth hacking" if you allow contributors to submit patches, because while pull requests are indirect, patches are self-contained. They are a unit of change. (I've referred to this in the past as using a strategy of dark patterns inspired by social networks.) I want to emphasize: "patches vs pull requests" is one matter, and "email vs web UI" is an entirely different matter. It's a 2×2 matrix, not a dichotomy. But this conversation has (annoyingly) run on as if it is "patches (which must be done through email) vs pull requests (which are done through point and click)". There's nothing that precludes GitHub from having built a web UI where today's "pull request" button ended with a "submit patch" button in its place. Nothing. > I don't see any way for that to not be trivial Yes, this is clear every time the conversation comes up. Something has happened wrt GitHub that causes people to a) forget how things looked before GitHub, b) have extreme difficulty imagining that things could work any other way—even when the other way is more straightforward and less convoluted than the way GitHub actually works. It's kind of nuts.
  - mememachine 10y ago
    It does leave a bad taste in my mouth that github is required, and they could easily do something about it. If they were open about it i probably wouldnt care, but this seems deceptive.
- 10y ago
y2kenny 10y ago
This is how you submit a patch to Gerrit: 1. Clone the repository locally 2. Make the fix 3. Run 'git push origin HEAD:refs/for/master'. Done (without needing to setup SMTP.)
- kiallmacinnes 10y ago
  Better yet, install `git-review`, a project that came out of OpenStack's use of Gerrit. 1. Clone the repository locally 2. Make the fix 3. Run 'git review'. Done (without needing to remember that annoying refs/for/foo syntax.)
- deleted 10y ago
  [deleted]
ajdlinux 10y ago
A casual contributor is more likely to already have a GitHub account than to have git-send-email configured correctly.
- mi100hael 10y ago
  Most maintainers aren't looking for "casual contributors." It's a huge pain in the ass to have someone open a half-baked PR and then never respond to feedback or support questions.
justinclift 10y ago
Just to point out, for drive by commits (eg typo fixes, etc), GitHub is super simple: 1. Go to the file in GitHub you want to change 2. Click the "Edit" icon 3. Click the "Create Pull Request" button There's no need to create a fork and branch manually any more, GitHub does it automatically behind the scenes. It's a useful optimisation. :)
- tracker1 10y ago
  Though I really wish that GH would cleanup the fork on your profile when the PR is closed, or offer an easy button to nuke those... Minor niggle.
  - justinclift 10y ago
    Yep, that would be useful. :)
tracker1 10y ago
Depends on the patch... if it's a typo fix on a readme, or updated url in a documentation file... you click the edit button on github, save, then create PR button after... easy peasy. It really depends on what you are trying to do in terms of what the process is.. generally, if you aren't a contrib, you will fork, and work from a branch on your locally cloned fork.. you push to that branch, and then create a PR upstream. You may create a local ref to the upstream branch in order to facilitate updates to your fork, and for handling squash/rebase scenarios. A lot of this is simply git... the "fork" on github creates a github hosted remote copy of the upstream project. The PR is a chance to review upstream patching. Yes, this can be done via email... but you can also do a lot of things in email, that email is a bad user experience for.
lmm 10y ago
Compare like with like, don't count screens one way and count preconfigured command lines the other way. If you have $VCS set up nicely, it's a one-liner there. If you have GitHub set up nicely, it's a one-liner in GitHub too. If you don't have $VCS set up, it's a large number of obscure manpages. If you don't have GitHub set up, it's a couple of clicks in a friendly UI (and actually far fewer clicks than you list, these days).

zAy0LfpBZLC8mAC 10y ago

I hate web because it provides a user interface instead of a programming interface. If I don't like the existing user interface to a standardized machine-readable protocol/format, I can write my own user interface for my own needs, as can anyone else, which has two big advantages: People with different needs can have user interfaces that match their respective needs, even while working on the same project, and that leads to easier innovation (when people share their respective solutions). Now, github currently provides the low-barrier solution that seems to be good enough for many people, which is why the development of tools for email-based workflows is stagnating, instead building more lock-in for github, and preventing any serious improvement in workflows. So, your hate for email is for practical reasons, but those practical reasons are not inherent properties of email, but rather the result of github trying to capture the market for later exploitation, and you are happy to help them for the momentary convenience, while probably not realizing how much potential convenience you are missing out on as a side effect.

notriddle 10y ago
> I hate web because it provides a user interface instead of a programming interface. https://api.github.com/ https://api.github.com/
- zAy0LfpBZLC8mAC 10y ago
  Which is mostly missing the point. First of all, github is not the web, and much of the web does not have an API (and I don't have a clue how good the github API is). But more importantly, even if they have an API: Is there any legally binding committment on their part that that API will be a reliable basis for me to build on for the next 20 years or so, assuming they still exist then? Won't they change it as it suits their needs, in particular their business needs? A "programming interface" that I can't rely on in the long run is still kindof a user interface, as I have to bother with it whenever it changes. It's a real programming interface only if I can build an abstraction on top of it and essentially forget the layers beneath.