6 ms·

This feels like an advertisement wrapped in a bad take. Speaking as someone who has a couple commits in the Linux kernel, yes the email thing is a pain to get s

by chomp 6y ago

This feels like an advertisement wrapped in a bad take. Speaking as someone who has a couple commits in the Linux kernel, yes the email thing is a pain to get started. Configuring your client to do the text thing, keeping up with conversations, learning who's who, you definitely can't jump straight in. The only way I was able to stay sane is setting up a bunch of filters to tag conversations and people. And that's not even mentioning the different patch submission guidelines, perl scripts I have to run, and other random things to make the patch even just readable by the community. Configuring all this stuff is definitely a barrier to entry. Now what tooling looks like to make it easier, that's an entire different conversation. Email has worked for the Linux dev community for decades and that should be protected and not disrupted. However, anyone who says there's no room to improve the onboarding experience, well, I just can't take their opinion seriously.

ddevault 6y ago
>However, anyone who says there's no room to improve the onboarding experience, well, I just can't take their opinion seriously. From TFA: > I agree that the UX of email-driven development could be better! This is followed by six examples of such improvements, the first of which is explicitly targeted at improving onboarding: https://git-send-email.io https://git-send-email.io
- corobo 6y ago
  All of that vs git pull/push.. best of luck to your thing but that sounds absolutely horrible
  - ddevault 6y ago
    This isn't a great take. I recorded a demonstration which shows the differences between the workflows more clearly: https://spacepub.space/videos/watch/1619c000-7c44-4330-9177-29a0854bd759 https://spacepub.space/videos/watch/1619c000-7c44-4330-9177-... After the initial setup, send-email is way faster.
    - corobo 6y ago
      I work at a web agency. Initial setup is frequent
      - ddevault 6y ago
        I don't understand how those follow. Note that your "initial setup" follows you from project to project and even machine to machine if you sync your config files.
        corobo 6y ago
        Ok that's fair and I overlooked a lot of it being a global config setup. It still stands though that you can cut out an entire page and a half of your instructions with "step 4: git push origin main" for each repo This isn't even taking into account getting other devs working with it, contractors we're working with, outside agencies that may be involved in this one How do you even get the patch into the repo from an email? I couldn't see that instruction but may have overlooked that too
        ddevault 6y ago
        Watch the video I linked to, please. You can't just `git push origin main` - you have to do that, then go to the web browser, create a fork, and open a pull request. And that's only if you already have a GitHub account. If you don't, add answering the registraiton email and adding your SSH key to those steps. In your situation, having a single shared git repo might make sense, sure. But we're not talking about that, we're talking about code review strategies.
        nonbirithm 6y ago
        > You can't just `git push origin main` - you have to do that, then go to the web browser, create a fork, and open a pull request. Not if you're using GitHub, because they have APIs for that: hub fork --remote-name origin git push origin feature hub ci-status --verbose hub pull-request https://hub.github.com/ https://hub.github.com/
- chomp 6y ago
  My man, those tools are great and I really respect the contribution of those tools to the community. But here's the kernel guidelines, which I am sure you are already familiar with: https://www.kernel.org/doc/html/latest/process/submitting-patches.html https://www.kernel.org/doc/html/latest/process/submitting-pa... Even with the tooling you provided, it's still a crappy experience (maybe a little less with the Sourcehut stuff). I know it's easy to read into the comments and be like "well this person just wants to shove the kernel into Microsoft's product," but it doesn't have to be this way. The sad thing is, for better or for worse, Github can handle almost all of those steps in the patch submission process, save for the ones where you have to actually describe what's changing. that's like, 15 steps that a newcomer does not have to even deal with. I think we all agree on "No Linux Kernel controlled by Microsoft platforms, please" but Sarah's comments that "this workflow sucks", and then your actions on "this workflow sucks" - y'all are saying the same thing.
  - ddevault 6y ago
    These "15 steps" are 90% unrelated to the email workflow, and would not be solved by GitHub. Did you read this document? It's telling you how to be a good contributor and the mechanics of how to contribute. That being said, this documentation is sorely in need of a git-oriented overhaul, assuming the programmer isn't using git is not doing any favors for the 99% who are.
manquer 6y ago
80% of my interaction with github is via email. I and am sure most people once they get used to email workflows will find email lot more effective than the UI. It is true you can only comment via github officially today and not create a pull request itself. It is trivial to use their read the email and use their API to create one. There are projects doing the other way [1] generating a email pull request. If there were "open standards" for pull requests/ Merge requests then git should have implemented it as part of the protocol the transportation medium is explicitly left out of the protocol for a good reason. [1] https://github.com/google/pull-request-mailer https://github.com/google/pull-request-mailer
- dgellow 6y ago
  If you only use emails for github issues and PRs, you’re missing edits made to comments after their publication.
kanox 6y ago
Using plain-text email for sending patches is fundamentally broken because it's just not a reliable transmission medium. SMTP is very old and very moldy and it's not something that you want to force your contributors should deal with. The first step is to always push you candidate commits to another inside a public git repo first. Unlike email the protocols underneath git push (ssh or https) are easy to use and operate reliably in all circumstances. > Email has worked for the Linux dev community for decades and that should be protected and not disrupted. No, it's wrong to protect workflows simply because they "old". There are many web-based code review solution out there and most of them are preferable to email.
- ddevault 6y ago
  OLD == BAD No, wrong. SMTP works fine and has done so for a long time, and it's incredibly easy to set up. It's the least of your problems when the rest of your task is patching the freaking Linux kernel. And as far as reliabilty is concerned, SMTP is one of the most reliable protocols on the internet. Compare with this: https://www.githubstatus.com/ https://www.githubstatus.com/
  - kanox 6y ago
    SMTP is terrible, especially for people with corporate accounts behind firewalls. I've contributed to linux in the past and dealing with corporate IT was a miserable experience and saw lots of other kernel developers waste their time fiddling with SMTP parameters. Those same firewalls can pass https or git+ssh just fine, it "just works". SMTP is not worth dealing with. Email is also not very good as a forum, for example you can't edit your posts for spelling fixes, archives are unreliable and hard to browse and it's difficult to map git commits to reviews. It's also wrong to claim that linux code review is somehow "distributed", it is very much centralized on a couple of mailing lists servers on vger.org. It would be much better if kernel maintainers kept their trees on github and started accepting PRs.
    - ignaloidas 6y ago
      It's not problem of SMTP or email in general that Outlook is trash. I get it, ages ago you bought into Microsoft's ecosystem, but can't you acknowledge it's flaws? If the server you're using doesn't let you send emails the way you want to, it's the problem of the server, not the email ecosystem in general.

by chomp 6y ago

ddevault 6y ago

>However, anyone who says there's no room to improve the onboarding experience, well, I just can't take their opinion seriously. From TFA: > I agree that the UX of email-driven development could be better! This is followed by six examples of such improvements, the first of which is explicitly targeted at improving onboarding: https://git-send-email.io https://git-send-email.io

corobo 6y ago
All of that vs git pull/push.. best of luck to your thing but that sounds absolutely horrible
- ddevault 6y ago
  This isn't a great take. I recorded a demonstration which shows the differences between the workflows more clearly: https://spacepub.space/videos/watch/1619c000-7c44-4330-9177-29a0854bd759 https://spacepub.space/videos/watch/1619c000-7c44-4330-9177-... After the initial setup, send-email is way faster.
  - corobo 6y ago
    I work at a web agency. Initial setup is frequent
    - ddevault 6y ago
      I don't understand how those follow. Note that your "initial setup" follows you from project to project and even machine to machine if you sync your config files.
      - corobo 6y ago
        Ok that's fair and I overlooked a lot of it being a global config setup. It still stands though that you can cut out an entire page and a half of your instructions with "step 4: git push origin main" for each repo This isn't even taking into account getting other devs working with it, contractors we're working with, outside agencies that may be involved in this one How do you even get the patch into the repo from an email? I couldn't see that instruction but may have overlooked that too
        ddevault 6y ago
        Watch the video I linked to, please. You can't just `git push origin main` - you have to do that, then go to the web browser, create a fork, and open a pull request. And that's only if you already have a GitHub account. If you don't, add answering the registraiton email and adding your SSH key to those steps. In your situation, having a single shared git repo might make sense, sure. But we're not talking about that, we're talking about code review strategies.
        nonbirithm 6y ago
        > You can't just `git push origin main` - you have to do that, then go to the web browser, create a fork, and open a pull request. Not if you're using GitHub, because they have APIs for that: hub fork --remote-name origin git push origin feature hub ci-status --verbose hub pull-request https://hub.github.com/ https://hub.github.com/
chomp 6y ago
My man, those tools are great and I really respect the contribution of those tools to the community. But here's the kernel guidelines, which I am sure you are already familiar with: https://www.kernel.org/doc/html/latest/process/submitting-patches.html https://www.kernel.org/doc/html/latest/process/submitting-pa... Even with the tooling you provided, it's still a crappy experience (maybe a little less with the Sourcehut stuff). I know it's easy to read into the comments and be like "well this person just wants to shove the kernel into Microsoft's product," but it doesn't have to be this way. The sad thing is, for better or for worse, Github can handle almost all of those steps in the patch submission process, save for the ones where you have to actually describe what's changing. that's like, 15 steps that a newcomer does not have to even deal with. I think we all agree on "No Linux Kernel controlled by Microsoft platforms, please" but Sarah's comments that "this workflow sucks", and then your actions on "this workflow sucks" - y'all are saying the same thing.
- ddevault 6y ago
  These "15 steps" are 90% unrelated to the email workflow, and would not be solved by GitHub. Did you read this document? It's telling you how to be a good contributor and the mechanics of how to contribute. That being said, this documentation is sorely in need of a git-oriented overhaul, assuming the programmer isn't using git is not doing any favors for the 99% who are.

manquer 6y ago

80% of my interaction with github is via email. I and am sure most people once they get used to email workflows will find email lot more effective than the UI. It is true you can only comment via github officially today and not create a pull request itself. It is trivial to use their read the email and use their API to create one. There are projects doing the other way [1] generating a email pull request. If there were "open standards" for pull requests/ Merge requests then git should have implemented it as part of the protocol the transportation medium is explicitly left out of the protocol for a good reason. [1] https://github.com/google/pull-request-mailer https://github.com/google/pull-request-mailer

dgellow 6y ago
If you only use emails for github issues and PRs, you’re missing edits made to comments after their publication.

kanox 6y ago

Using plain-text email for sending patches is fundamentally broken because it's just not a reliable transmission medium. SMTP is very old and very moldy and it's not something that you want to force your contributors should deal with. The first step is to always push you candidate commits to another inside a public git repo first. Unlike email the protocols underneath git push (ssh or https) are easy to use and operate reliably in all circumstances. > Email has worked for the Linux dev community for decades and that should be protected and not disrupted. No, it's wrong to protect workflows simply because they "old". There are many web-based code review solution out there and most of them are preferable to email.

ddevault 6y ago
OLD == BAD No, wrong. SMTP works fine and has done so for a long time, and it's incredibly easy to set up. It's the least of your problems when the rest of your task is patching the freaking Linux kernel. And as far as reliabilty is concerned, SMTP is one of the most reliable protocols on the internet. Compare with this: https://www.githubstatus.com/ https://www.githubstatus.com/
- kanox 6y ago
  SMTP is terrible, especially for people with corporate accounts behind firewalls. I've contributed to linux in the past and dealing with corporate IT was a miserable experience and saw lots of other kernel developers waste their time fiddling with SMTP parameters. Those same firewalls can pass https or git+ssh just fine, it "just works". SMTP is not worth dealing with. Email is also not very good as a forum, for example you can't edit your posts for spelling fixes, archives are unreliable and hard to browse and it's difficult to map git commits to reviews. It's also wrong to claim that linux code review is somehow "distributed", it is very much centralized on a couple of mailing lists servers on vger.org. It would be much better if kernel maintainers kept their trees on github and started accepting PRs.
  - ignaloidas 6y ago
    It's not problem of SMTP or email in general that Outlook is trash. I get it, ages ago you bought into Microsoft's ecosystem, but can't you acknowledge it's flaws? If the server you're using doesn't let you send emails the way you want to, it's the problem of the server, not the email ecosystem in general.