6 ms·

>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

>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/
        ddevault 6y ago
        Install and learn how to use more third-party software to use a propreitary API on a centralized, proprietary, unreliable service... or just use the built-in git tooling?
        rfoo 6y ago
        Where is the builtin git tooling for showing side by side diff with proper syntax and different parts highlighting, and make it possible to turn my review comments back to the "bottom-posting" style text emails interleaved with the inline diff everyone on the mailing list strongly insisting? I'm sorry but I'm a stupid noob and my eye is not able to parse codes without syntax highlighting.
        ddevault 6y ago
        It's called your email client.
        6y ago
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.

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/
        ddevault 6y ago
        Install and learn how to use more third-party software to use a propreitary API on a centralized, proprietary, unreliable service... or just use the built-in git tooling?
        rfoo 6y ago
        Where is the builtin git tooling for showing side by side diff with proper syntax and different parts highlighting, and make it possible to turn my review comments back to the "bottom-posting" style text emails interleaved with the inline diff everyone on the mailing list strongly insisting? I'm sorry but I'm a stupid noob and my eye is not able to parse codes without syntax highlighting.
        ddevault 6y ago
        It's called your email client.
        6y ago

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.