3 ms·

Bring up arguments, don't tell someone to shut up because you don't share their opinion. Also, if the entire world would think like "30 years it worked fine",

Bring up arguments, don't tell someone to shut up because you don't share their opinion. Also, if the entire world would think like "30 years it worked fine", there would be absolutely no technology improvements the past 30 years.

u801e 5y ago
Does Github work on a dial up connection? Does it work when you don't have an internet connection? Improvements in technology can do everything that old technology can do and more. Not supporting use cases that old technology did isn't an improvement.
- JasonFruit 5y ago
  You know, that's not really true. For road transportation, a car is a great improvement on a horse — but it can't take you home when you're too drunk to guide it. Some things are an improvement in general, but still a compromise. A stronger argument would explain why the better technology is a bad compromise for this application.
  - u801e 5y ago
    You're working off an assumption that Github is a better technology. Many people who make this argument do not have extensive experience using both technologies. The arguments I've seen presented comes down to the fact that people cannot figure out how to set up email clients or how to send patch sets via email. It's not around an actual comparison of how these technologies operate or what compromises one has to make to use email versus Github or vice-versa.
    - JasonFruit 5y ago
      I see that argument about client setup too, but it's not the reason I don't prefer email, especially for something like kernel development. I think there are real disadvantages to the sort of queue management required of the maintainer using email that can be alleviated by a specialized tool. It also separates the communication history from the code history, which can sometimes lead to confusion about when a specific person became aware of a patch, which is often important. I'm usually against integrating too many functions, but I think GitHub does a good job of it. Basically, I prefer GitHub's approach. I'm not deeply experienced managing open source projects, though, so my opinion is not that valuable. My basic contention was with the idea that a technology can't be better unless it's an unmixed good.

u801e 5y ago

Does Github work on a dial up connection? Does it work when you don't have an internet connection? Improvements in technology can do everything that old technology can do and more. Not supporting use cases that old technology did isn't an improvement.

JasonFruit 5y ago
You know, that's not really true. For road transportation, a car is a great improvement on a horse — but it can't take you home when you're too drunk to guide it. Some things are an improvement in general, but still a compromise. A stronger argument would explain why the better technology is a bad compromise for this application.
- u801e 5y ago
  You're working off an assumption that Github is a better technology. Many people who make this argument do not have extensive experience using both technologies. The arguments I've seen presented comes down to the fact that people cannot figure out how to set up email clients or how to send patch sets via email. It's not around an actual comparison of how these technologies operate or what compromises one has to make to use email versus Github or vice-versa.
  - JasonFruit 5y ago
    I see that argument about client setup too, but it's not the reason I don't prefer email, especially for something like kernel development. I think there are real disadvantages to the sort of queue management required of the maintainer using email that can be alleviated by a specialized tool. It also separates the communication history from the code history, which can sometimes lead to confusion about when a specific person became aware of a patch, which is often important. I'm usually against integrating too many functions, but I think GitHub does a good job of it. Basically, I prefer GitHub's approach. I'm not deeply experienced managing open source projects, though, so my opinion is not that valuable. My basic contention was with the idea that a technology can't be better unless it's an unmixed good.