13 ms·

I appreciate the effort here, but after learning the workflow and having to get all this set up on a few computers, having to configure git send-mail is honestl

I appreciate the effort here, but after learning the workflow and having to get all this set up on a few computers, having to configure git send-mail is honestly just needlessly annoying and absurd. Organizations that insist on using workflows like git send-mail and mailing lists not only drive away a significant number of potential contributors, but they also form a weirdly religious culture that fetishizes needlessly painful process and is incapable of improvement

ploum 3y ago
Organizations that insists on using a web interface and ever-changing click workflows not only drive away a significant number of very knowledgeable contributors, but they also form a weirdly irrational culture that fetishizes needlessly graphical content, marketing and fake-usability detrimental to learnability and integration with each user workflow.
- sneak 3y ago
  “needlessly graphical” requires a citation when it’s clear that if you use a web GUI for this you address a market of potential contributors that is three to six orders of magnitude larger. srht is really designed for (and thus only really useful for) lone wolf developers who collaborate rarely, if ever, and with a very small number of collaborators who collaborate infrequently. It is not built for large teams with constant active collaboration, it falls down for this use case. It’s hobby software for hobby users. (I don’t think this is a bad thing, but you should be aware of the product design goals of its author.)
  - ploum 3y ago
    [flagged]
    - sneak 3y ago
      That’s your bias showing; GitHub is primarily designed for getting work done, as it is a paid service that needs to serve its customers.
      - earthboundkid 3y ago
        I think GitHub was designed for getting work done, but since Microsoft bought them, they are slowly moving into enshitification territory. For example, they have a homepage that is just a wanna be social media feed and the file contents pages have ads for Copilot and in general there are ads for VSCode and blah blah. It was pretty good, but it's going to get much worse. :-)
        BaculumMeumEst 3y ago
        I disagree on enshittification. The only practical change I've noticed in github usage is the improvements to code search, which has been unbelievably useful. It gives me the ability to do complex searches to find real usages of even the most obscure libraries, examples of poorly documented configuration files, and more, from any public repository hosted anywhere on github. That capability comes from both the large body of source code available to the platform, and the large amount of engineering work put into that particular feature. It is one of many usability benefits is not available anywhere else.
        earthboundkid 3y ago
        The new code search stuff is very good, yes. "Enshitification" is rapidly becoming a meaningless term of disapproval, but it had a precise definition when Doctorow coined it: > This is enshittification: surpluses are first directed to users; then, once they're locked in, surpluses go to suppliers; then once they're locked in, the surplus is handed to shareholders and the platform becomes a useless pile of shit. GitHub directed a huge surplus to developers compared to what came before it. Microsoft bought it and worked on furthering the lock in with Actions, and now the ship is slowly moving towards wringing the extra value out of us. It's not at the bottom of the hill yet, but it's definitely on the slope. They already have ads for themselves on it. The ads are just going to slowly creep outwards as necessary to produce a smooth revenue curve.
    - sigterminus 3y ago
      [dead]
  - 418tpot 3y ago
    Some of the largest and most important software is developed over email, e.g. Linux, QEMU, Firefox, etc... Don't make the mistake thinking that email doesn't scale. In fact, for most teams, the opposite is true.
    - bitcharmer 3y ago
      This is like saying that pyramids were constructed without modern cranes and bulldozers so obviously it's the right way to build stuff today. It's clearly not true but there are many power-wielding individuals in these projects who prefer to browse the web with lynx or develop in emacs and will impose this on anyone that would like to participate. This is wrong.
      - r053bud 3y ago
        No one is forcing you to contribute to, or even use, software that uses an email-based workflow. I’d also put money on the fact that the majority of contributors to Linux, an extremely successful free software project, prefer the email-based workflow.
        bitcharmer 3y ago
        > No one is forcing you to contribute This is exactly the problematic attitude. I'm an OpenJDK author but not linux kernel contributor for mainly this reason. There are many people like me. > majority of contributors to Linux, an extremely successful free software project, prefer the email-based workflow This reminds me the many absurd conversations I had from my time in Goldman Sachs, few years ago. People with 15+ year tenures claiming Slang is the best answer to any- and everything. They just didn't know any better and stubbornly stuck to tooling and mindset straight out of 1995.
        necrotic_comp 3y ago
        Not to derail the conversation, but Slang is incredible. Its interface is old and archaic, sure, but it's the best and most expressive coding experience I've ever had. It took some getting used to (especially case-insensitive variables with spaces ?! and the UFOs) but I really enjoyed working in it. All of the other workflow tools, like Procmon, were icing on the cake. The internal cloud was just getting up to speed when I left, and that was more modern and also a joy to use. There's a lot to dislike about working there, but in my experience, the firmwide tooling was excellent.
  - yjftsjthsd-h 3y ago
    > when it’s clear that if you use a web GUI for this you address a market of potential contributors that is three to six orders of magnitude larger. You cannot possibly claim that the other side needs to cite their sources and then throw numbers like that out without any backing.
- pjerem 3y ago
  I have no great love for GitHub, I avoid it for my own projects but their official cli client is pretty functional and there are just tons of other clients, graphical or not for GitHub, GitLab etc … I say that as someone who don’t like GitHub, but overall it’s far from the worst tool an employer may impose to its employees.
- fodkodrasz 3y ago
  In case of GitHub you have this for example : https://cli.github.com/ https://cli.github.com/ It is often used in GitHub CI workflows.
- raincole 3y ago
  GUI is fake-usability now? Fake Edit: Oh this is HN. Never mind then.
  - BaculumMeumEst 3y ago
    Isn't it weird that such people bother installing a windowing system at all? Just work off the login terminal bro, it's perfection.
- howenterprisey 3y ago
  What on earth is "fake-usability"? It's more usable, just admit it.
  - BaculumMeumEst 3y ago
    Fake-usability is when 97/100 software developers find something more usable, but it's fake because I've invested a lot of time doing it a different way and gotten used to it.
    - sigterminus 3y ago
      [dead]
- keepamovin 3y ago
  This is well said and insightful! I will reflect on this kind of phenomena and suspect I will be able to see it in the world going forward. Awareness of this will be useful to avoid the pitfalls described here. Thank you for making this contribution! :) I funnily think that many of the people poo-pooing the email patch method here, would just as merrily join in on HN were it an email mailing list collection, haha! :)
tjoff 3y ago
Why would you set it up more than once? Copy the config, or better yet, version control it (or any of the other solutions to this problem).
emptysongglass 3y ago
It really kills the fun when contributing to any FOSS project that fetishizes these tools and holds them up as some kind of proof of hacker cred. I've given up. The latency is too high and the tools are terrible.
- oefrha 3y ago
  “Want to contribute? Subscribe to our mailing list that sends a hundred emails a day.” Nope.
  - catern 3y ago
    You don't have to subscribe to send a patch to a mailing list.
    - sjamaan 3y ago
      Presumably you'd be interested in any feedback, and not everyone CCs the original author in their reply.
      - nolist_policy 3y ago
        Reply-to-all is the standard policy on most mailing lists. Especially on -devel lists since you'll pull in (CC:) people outside of the mailing list (cross-project) into discussions from time to time.
        Avamander 3y ago
        I know more than one occasion where that has gotten an angry reply. It's also not the default in many clients. It's tedious and error-prone.
    - oefrha 3y ago
      I have more than once subscribed just to report a bug or send a patch because the mailing list rejects emails from non-subscribers. Edit: Btw, yes I have done the periodically-check-archive thing in the past, thank you. Hated it. Also missed a response once because I forgot to check and replier didn't CC. I realized like a month later.
severus_snape 3y ago
# do your code change git commit git send-email --to=<some mailing list> -1 # amend your change git commit --amend git send-email -v2 --to=<some mailing list> -1 I'm not sure what is needlessly annoying and absurd. Edit with minimal configuration: cat ~/.gitconfig [user] email = your@mail.address name = Your Name [sendemail] smtpuser = your@mail.address smtpserver = smtp.whatever.com smtpserverport = 587 smtpencryption = tls
- MaxBarraclough 3y ago
  They said they found it difficult to configure, not that they found it difficult to use afterwards.
  - deleted 3y ago
    [deleted]
  - tlamponi 3y ago
    If your system cannot relay mail correctly already, as most office setups are easy to configure to be able to provide that without extra config, at least for Linux setups, then the set up means having something like the following in their gitconfig: cat .gitconfig # snip [sendemail] to = default@list.example.com annotate = yes suppresscc = self smtpencryption=tls smtpserver=imap.example.com smtpserverport=587 smtpuser=foo.bar@example.com (only the ones starting with "smtp" are relevant for mail, the other ones are just there for convenience) And that has to be done once, iow., in essence it's as hard a setting up an email fat client like thunderbird.
    - earthboundkid 3y ago
      FWIW, I haven't done that kind of setup for years because modern iOS/macOS does email server discovery, where you enter "bob@example.com" and then it does discovery and figures out the right imap.example.com:587 etc for you by looking at DNS.
      - 3y ago
tlamponi 3y ago
Configuring git send-email is trivial, definitively faster than creating an account at some web UI from a "source forge" – it's literally setting a handful of properties in the `.gitconfig` – and those are not specific to a project, but just your mail server settings you can reuse them for any project that accept patches over mailing lists. And using it for a project that accepts this workflow is such a joy, no need to figure out weird merge request that make me re-enter all the information I had in my git commits already. If it's only a few patches, say three, I can do a simple `git send-email --to mailing@list.example.com -3`, maybe throw in `--cover-letter` for some meta info if the changes are even big enough to require that, and be done. Certainly to each their own workflow, and once can get accustomed to a lot of needless tasks and workflows, but how one can look at the bloated interfaces that try hard to add vendor-lock-in and say "this is so much simpler and easier to grasp" can IMO only mean they never tried this way in good faith. In the end sending a mail is trivial, and code changes are text (most of the time), it can hardly be beat in simplicity. Anecdotally, most of our new hires from the last years had no experience with the email workflow, and a few weeks in most of them find it way better, while the rest finds it at least as good as the alternatives (and here they mean gitea or sourcehut, not the monsters that GitHub/Lab are).
- ligurio 3y ago
  > Configuring git send-email is trivial, definitively faster than creating an account at some web UI from a "source forge" <snipped>. You forgot that mailing list requires subscription and in some cases it could be a tricky. Without proper subscriptions and confirming subscription, your mails with patches will go to trash.
  - severus_snape 3y ago
    There is usually no need to subscribe.
    - nolist_policy 3y ago
      This. You just To: the mailing-list and depending on the project CC: the maintainers. No subscribing needed. Standard policy on all mailing lists is to reply-to-all so you'll get always CC'ed on replies. This also makes it very easy to pull in more people into a discussion, even across different projects.
nicoco 3y ago
It's also possible to not be religious about it. Git is distributed. I have projects on srht and contributing does not mandate using the send-email workflow. "Push it somewhere and let me know where I can pull" always works too.
TotempaaltJ 3y ago
Hard agree! I think the success of Github's PR system over Git + email workflows has proved itself quite well through sheer adoption numbers.
- tristan957 3y ago
  The largest open-source software projects in the world don't use it though, so that tells me there is something lacking.
  - bitcharmer 3y ago
    Maybe so, but my interpretation is that there's personal opposition to change and improvement from people like Linus or TGLX or other greybeards. At least in the linux kernel world. The contribution by email is an antiquated approach and needs to go. Now, knowing the HN crowd this comment will become grey in 3... 2... 1...
    - ungamedplayer 3y ago
      They say that scientific discovery advanced one death at a time. I imagine this same theory applies to kernel development tooling. I understand not changing for change sake. The kernel is at this time not "this gen" developer friendly.
    - tristan957 3y ago
      What is antiquated about sending patches via email? Have you ever used email to contribute to a project or review a patch?
      - atomicUpdate 3y ago
        Contributing patches via the Linux mailing lists is worse than Gerrit in every way.
        tlamponi 3y ago
djha-skin 3y ago
> not only drive away a significant number of potential contributors, It drives away the kind of people who have little patience for technology problems and little patience for learning new things. I don't want those kind of people working on e.g. Git. Git needs people who have lots of patience for technology problems and lots of patience for learning new things.
- tmpX7dMeXU 3y ago
  Oh please. Lots of people, myself included, take issue with having to answer your riddles three before I may cross the bridge that you value much more than I do. There’s having patience and problem-solving ability, and there’s not seeing the value in jumping through the various hoops that comprise some ‘90s Internet fetishist’s playground. This is all just code for “I’m old, set in my ways, and don’t appreciate the fact that the only reason I find my workflow easier is because I know it, not because it’s more intuitive than what people are doing these days”.
- fodkodrasz 3y ago
  > It drives away the kind of people who have little patience for technology problems and little patience for learning new things. like learning to use a GUI and a Web Interface?
  - scbrg 3y ago
    It's not really that people can't use them. It's that they're slow, annoying, hard/impossible to automate, hard/impossible to customize and give you RSI. We've seen Web interfaces, they're hard to avoid. We've just decided that they're worse.
    - fodkodrasz 3y ago
      Could you, for a moment, imagine that others might feel like that about the command-line-plain-text-email-to-mailing-list workflows? Possibly not, as you have labelled them > the kind of people who have little patience for technology problems and little patience for learning new things Also tell me how is tolerating rude incumbents of mailing list sending email with 50+ characters in a line a technical problem? (Yes they are often rude, and unwelcoming to those attempting to accept their anachronistic ways. You are demonstrating that specific behaviour right here, which many of us have encountered on those projects.) I think the projects which accept contributions only from mailing lists will have their contributors die out, or will be forced to change their ways to survive. I for one will never again attempt to contribute to such project, thanks to the inflexibility of the incumbents I have faced several times. Also thanks to the sub-par review workflow, usually the lacking quick CI feedback. Web UI might give you RSI, but the insufferable email-only-patches people give me PTSD from my previous encounters. ps: if you are willing to learn new things, you can automate web apps and GUI apps (eg. Autoit, xaut). Some even have proper APIs (COM/dbus/web api), or a cli!
sbjs 3y ago
There's a psychological basis for people taking pride in a difficult task learned and mastered, and many organizations take advantage of this by creating a culture that rewards this effort when put towards their own products with social status within the organization. It feels manipulative and unethical to me.
- sbjs 3y ago
  (Dare I say HN is one of them, where the effort is a curated form of elitism, and the mechanism up/down votes?)
- carapace 3y ago
  Like GitHub.
gwd 3y ago
Our project inherited a patchbomb-based workflow from Linux. Many of the individual members have also contributed to gitlab/hub based projects, and appreciated a lot of the automation available, as well as recognizing the lower barrier-to-entry of not having to figure out how to get an SMTP connection. So a few years ago we experimented with allowing "small" patches to be sent via PR on gitlab, and doing the review there. Basically, everyone agreed that actually doing the review on gitlab was a lot worse compared to email. There's just so much more flexibility. It's not off the table that we may give it a try again, because the advantages of having concrete pull requests (and issues and...) rather than patch series is pretty significant. But if you're familiar with doing email-based review, I think it's still a far superior; and you're definitely giving something up when you move away from it.
- 0xffff2 3y ago
  >Basically, everyone agreed that actually doing the review on gitlab was a lot worse compared to email. There's just so much more flexibility. Could you elaborate? This is truly shocking to me. Admittedly I have never worked on a project with an email-based workflow, but I can't think of how email would allow comments inline with the patch, which is an incredibly beneficial feature to me.
  - gwd 3y ago
    Well yeah, replying in-line to the patch to make comments is definitely a requirement. :-) You always reply with quotes; and you always reply inline, below the thing you're replying to. Quoted material is typically indicated by '>'. So for one thing, you can easily trim your reply to just the bits of the patch that you think is important; that makes it easy for anyone reading; you don't have to skip over large parts of the thread. Then you can also re-arrange what you're replying to, to make it make your reply make more sense. Furthermore, suppose A replies to the patch and makes comments 1, 2, and 3 (inline in a single email). When person B replies to A's email, they typically also send a single email, perhaps with replies 1' and 3' (trimming out comment 2, which they don't care about). This means if you've read A's mail, you can just read B's mail, and all the "new" comments are collected in one place (with the thing they're replying to). Contrast the above with gitlab, where A's replies 1, 2, and 3 are spread throughout the patch; and B's replies will also be spread out, meaning you have a kind of discoverability problem to see both 1' and 3'. And suppose in the course of talking about something you realize this bug may actually be a security issue -- you can remove the list, cc' "security@", and pick up the discussion without having to do any copy & paste. Same goes if you want to make a private comment, or bring something to someone's attention; just reply, remove everyone else, and say "FYI". I wish I had a really good recent example to show you, but a quick skim of today's threads isn't anything special. :-) I mean, I was arguing with people online [1] on BBS's in the early 90's, and I was on Usenet back when that was the main social network; so this "reply and comment inline" way of having a discussion is pretty well ingrained for me. But there are people on my team in their early 30's who also took to the email workflow really quickly too. [1] https://xkcd.com/386/ https://xkcd.com/386/
diogenes4 3y ago
> Organizations that insist on using workflows like git send-mail and mailing lists not only drive away a significant number of potential contributors, but they also form a weirdly religious culture that fetishizes needlessly painful process and is incapable of improvement You could say the same of GitHub. Why do I need an account on your lil site just to get a patch accepted?
grayhatter 3y ago
> Organizations that insist on using workflows like git send-mail and mailing lists not only drive away a significant number of potential contributor Often that's a bonus if not the whole point to begin with. The higher the barrier to entry the less noise you need to filter through. It only feels annoying to you because you're not used to it.
0xbadcafebee 3y ago
> workflows like git send-mail and mailing lists not only drive away a significant number of potential contributors A GitHub PR is way more steps than e-mailing a patch to a mailing list, and far less accessible. Have you never done the "sign the contributor license agreement and get the GitHub bot to approve it" polka? I've done it a dozen times now, it's painful and way more gatekeepery than just emailing a patch. > but they also form a weirdly religious culture that fetishizes needlessly painful process and is incapable of improvement Who hurt you?
carapace 3y ago
You went from "I find it inconvenient" to "they're masochistic cultists" pretty quickly there. Ad hominem attacks are against site policy. You've spawned a huge thread of people being incredibly self-righteous about the mind-boggling difficulty of sending email. It makes me think that it's actually a great filter to keep out people who prefer drama to clicking a few buttons that are different than the buttons they're used to clicking. I understand that familiarity is a powerful driving force in human psychology, but really, it's not like it's that hard to learn a different flow. I mean, I've had to use Perforce, and while it's fun to complain, it really wasn't that hard. I didn't even have to get out of my chair.
moritzwarhier 3y ago
The process tends to be a lot less painful when using git-combine-mailmap [1] ^1 https://git-man-page-generator.lokaltog.net/#Y29tYmluZSQkbWFpbG1hcA== https://git-man-page-generator.lokaltog.net/#Y29tYmluZSQkbWF...
wkz 3y ago
It's easy to forget the maintainers' side of this. Yes, most contributors will prefer opening a PR on GitHub as apposed to mailinglists. But imagine instead that you are David Miller, and it's your job to consume the absolute fire hose of patches and messages related to Linux's networking subsystem. Would you rather wade through the hundreds of messages and patches coming in every day using either GitHub PRs and issues or email? I would choose email for one simple reason: It's easier to script. Even as a small-time contributor and observer to that space, I couldn't even imagine trying to keep up with everything going on if I couldn't bulk download, filter, tag etc. As a maintainer it would be excruciating.
- jeffybefffy519 3y ago
  Github has an api for this…
  - diggan 3y ago
    Which eventually will change, and you have to update everything. Or the company disappears and you have to move somewhere else. Email is just email. You write SMTP/IMAP clients today and they'll continue to work for a long time, probably longer than most platforms with APIs online today.
  - wkz 3y ago
    And once you've used that API to download and tag everything, what tools do you use to interactively view the results, run search queries, apply patches to local trees etc? If your on-disk format is an Mbox or a Maildir, you can use tools like notmuch and its emacs integration to do it. Now don't get me wrong; I love GitHub. I host all my projects there, and I prefer PRs+issues to mailinglists in almost all cases. But for massive projects like Linux, a mailinglist (and associated tooling) scales better, in my opinion.
- myaccountonhn 3y ago
  It’s easier for contributors too, you don’t need an account.
myaccountonhn 3y ago
I personally self host git and think that email gives a bunch of advantages: 1. Email has clients with full offline support. Sometimes I work in locations where internet is bad to nonexistent and with github I am limited in what I can do. 2. Anyone can contribute to my repos without needing to sign up to my website. Git with email truly allows decentralization of “forges”. So in the same vain, I can contribute with the same client to any project on the web that accepts email patches and it’s the same workflow for all of them. 3. Since I have an email client for my email, I can set up my own custom workflow that is much faster. Github siloes you into a begrudgingly slow one. My email client integrates into my editor and gives me the same keyboard shortcuts I use to navigate my code. 4. Did I mention it removes centralization? Having github be the center for all repos makes it ripe for enshittification. Given Microsoft’s history for EEE, I don’t trust them one bit.

ploum 3y ago

Organizations that insists on using a web interface and ever-changing click workflows not only drive away a significant number of very knowledgeable contributors, but they also form a weirdly irrational culture that fetishizes needlessly graphical content, marketing and fake-usability detrimental to learnability and integration with each user workflow.

sneak 3y ago
“needlessly graphical” requires a citation when it’s clear that if you use a web GUI for this you address a market of potential contributors that is three to six orders of magnitude larger. srht is really designed for (and thus only really useful for) lone wolf developers who collaborate rarely, if ever, and with a very small number of collaborators who collaborate infrequently. It is not built for large teams with constant active collaboration, it falls down for this use case. It’s hobby software for hobby users. (I don’t think this is a bad thing, but you should be aware of the product design goals of its author.)
- ploum 3y ago
  [flagged]
  - sneak 3y ago
    That’s your bias showing; GitHub is primarily designed for getting work done, as it is a paid service that needs to serve its customers.
    - earthboundkid 3y ago
      I think GitHub was designed for getting work done, but since Microsoft bought them, they are slowly moving into enshitification territory. For example, they have a homepage that is just a wanna be social media feed and the file contents pages have ads for Copilot and in general there are ads for VSCode and blah blah. It was pretty good, but it's going to get much worse. :-)
      - BaculumMeumEst 3y ago
        I disagree on enshittification. The only practical change I've noticed in github usage is the improvements to code search, which has been unbelievably useful. It gives me the ability to do complex searches to find real usages of even the most obscure libraries, examples of poorly documented configuration files, and more, from any public repository hosted anywhere on github. That capability comes from both the large body of source code available to the platform, and the large amount of engineering work put into that particular feature. It is one of many usability benefits is not available anywhere else.
        earthboundkid 3y ago
        The new code search stuff is very good, yes. "Enshitification" is rapidly becoming a meaningless term of disapproval, but it had a precise definition when Doctorow coined it: > This is enshittification: surpluses are first directed to users; then, once they're locked in, surpluses go to suppliers; then once they're locked in, the surplus is handed to shareholders and the platform becomes a useless pile of shit. GitHub directed a huge surplus to developers compared to what came before it. Microsoft bought it and worked on furthering the lock in with Actions, and now the ship is slowly moving towards wringing the extra value out of us. It's not at the bottom of the hill yet, but it's definitely on the slope. They already have ads for themselves on it. The ads are just going to slowly creep outwards as necessary to produce a smooth revenue curve.
  - sigterminus 3y ago
    [dead]
- 418tpot 3y ago
  Some of the largest and most important software is developed over email, e.g. Linux, QEMU, Firefox, etc... Don't make the mistake thinking that email doesn't scale. In fact, for most teams, the opposite is true.
  - bitcharmer 3y ago
    This is like saying that pyramids were constructed without modern cranes and bulldozers so obviously it's the right way to build stuff today. It's clearly not true but there are many power-wielding individuals in these projects who prefer to browse the web with lynx or develop in emacs and will impose this on anyone that would like to participate. This is wrong.
    - r053bud 3y ago
      No one is forcing you to contribute to, or even use, software that uses an email-based workflow. I’d also put money on the fact that the majority of contributors to Linux, an extremely successful free software project, prefer the email-based workflow.
      - bitcharmer 3y ago
        > No one is forcing you to contribute This is exactly the problematic attitude. I'm an OpenJDK author but not linux kernel contributor for mainly this reason. There are many people like me. > majority of contributors to Linux, an extremely successful free software project, prefer the email-based workflow This reminds me the many absurd conversations I had from my time in Goldman Sachs, few years ago. People with 15+ year tenures claiming Slang is the best answer to any- and everything. They just didn't know any better and stubbornly stuck to tooling and mindset straight out of 1995.
        necrotic_comp 3y ago
        Not to derail the conversation, but Slang is incredible. Its interface is old and archaic, sure, but it's the best and most expressive coding experience I've ever had. It took some getting used to (especially case-insensitive variables with spaces ?! and the UFOs) but I really enjoyed working in it. All of the other workflow tools, like Procmon, were icing on the cake. The internal cloud was just getting up to speed when I left, and that was more modern and also a joy to use. There's a lot to dislike about working there, but in my experience, the firmwide tooling was excellent.
- yjftsjthsd-h 3y ago
  > when it’s clear that if you use a web GUI for this you address a market of potential contributors that is three to six orders of magnitude larger. You cannot possibly claim that the other side needs to cite their sources and then throw numbers like that out without any backing.
pjerem 3y ago
I have no great love for GitHub, I avoid it for my own projects but their official cli client is pretty functional and there are just tons of other clients, graphical or not for GitHub, GitLab etc … I say that as someone who don’t like GitHub, but overall it’s far from the worst tool an employer may impose to its employees.
fodkodrasz 3y ago
In case of GitHub you have this for example : https://cli.github.com/ https://cli.github.com/ It is often used in GitHub CI workflows.
raincole 3y ago
GUI is fake-usability now? Fake Edit: Oh this is HN. Never mind then.
- BaculumMeumEst 3y ago
  Isn't it weird that such people bother installing a windowing system at all? Just work off the login terminal bro, it's perfection.
howenterprisey 3y ago
What on earth is "fake-usability"? It's more usable, just admit it.
- BaculumMeumEst 3y ago
  Fake-usability is when 97/100 software developers find something more usable, but it's fake because I've invested a lot of time doing it a different way and gotten used to it.
  - sigterminus 3y ago
    [dead]
keepamovin 3y ago
This is well said and insightful! I will reflect on this kind of phenomena and suspect I will be able to see it in the world going forward. Awareness of this will be useful to avoid the pitfalls described here. Thank you for making this contribution! :) I funnily think that many of the people poo-pooing the email patch method here, would just as merrily join in on HN were it an email mailing list collection, haha! :)

tjoff 3y ago

Why would you set it up more than once? Copy the config, or better yet, version control it (or any of the other solutions to this problem).

emptysongglass 3y ago

It really kills the fun when contributing to any FOSS project that fetishizes these tools and holds them up as some kind of proof of hacker cred. I've given up. The latency is too high and the tools are terrible.

oefrha 3y ago
“Want to contribute? Subscribe to our mailing list that sends a hundred emails a day.” Nope.
- catern 3y ago
  You don't have to subscribe to send a patch to a mailing list.
  - sjamaan 3y ago
    Presumably you'd be interested in any feedback, and not everyone CCs the original author in their reply.
    - nolist_policy 3y ago
      Reply-to-all is the standard policy on most mailing lists. Especially on -devel lists since you'll pull in (CC:) people outside of the mailing list (cross-project) into discussions from time to time.
      - Avamander 3y ago
        I know more than one occasion where that has gotten an angry reply. It's also not the default in many clients. It's tedious and error-prone.
  - oefrha 3y ago
    I have more than once subscribed just to report a bug or send a patch because the mailing list rejects emails from non-subscribers. Edit: Btw, yes I have done the periodically-check-archive thing in the past, thank you. Hated it. Also missed a response once because I forgot to check and replier didn't CC. I realized like a month later.

severus_snape 3y ago

# do your code change git commit git send-email --to=<some mailing list> -1 # amend your change git commit --amend git send-email -v2 --to=<some mailing list> -1 I'm not sure what is needlessly annoying and absurd. Edit with minimal configuration: cat ~/.gitconfig [user] email = your@mail.address name = Your Name [sendemail] smtpuser = your@mail.address smtpserver = smtp.whatever.com smtpserverport = 587 smtpencryption = tls

MaxBarraclough 3y ago
They said they found it difficult to configure, not that they found it difficult to use afterwards.
- deleted 3y ago
  [deleted]
- tlamponi 3y ago
  If your system cannot relay mail correctly already, as most office setups are easy to configure to be able to provide that without extra config, at least for Linux setups, then the set up means having something like the following in their gitconfig: cat .gitconfig # snip [sendemail] to = default@list.example.com annotate = yes suppresscc = self smtpencryption=tls smtpserver=imap.example.com smtpserverport=587 smtpuser=foo.bar@example.com (only the ones starting with "smtp" are relevant for mail, the other ones are just there for convenience) And that has to be done once, iow., in essence it's as hard a setting up an email fat client like thunderbird.
  - earthboundkid 3y ago
    FWIW, I haven't done that kind of setup for years because modern iOS/macOS does email server discovery, where you enter "bob@example.com" and then it does discovery and figures out the right imap.example.com:587 etc for you by looking at DNS.
    - 3y ago

tlamponi 3y ago

Configuring git send-email is trivial, definitively faster than creating an account at some web UI from a "source forge" – it's literally setting a handful of properties in the `.gitconfig` – and those are not specific to a project, but just your mail server settings you can reuse them for any project that accept patches over mailing lists. And using it for a project that accepts this workflow is such a joy, no need to figure out weird merge request that make me re-enter all the information I had in my git commits already. If it's only a few patches, say three, I can do a simple `git send-email --to mailing@list.example.com -3`, maybe throw in `--cover-letter` for some meta info if the changes are even big enough to require that, and be done. Certainly to each their own workflow, and once can get accustomed to a lot of needless tasks and workflows, but how one can look at the bloated interfaces that try hard to add vendor-lock-in and say "this is so much simpler and easier to grasp" can IMO only mean they never tried this way in good faith. In the end sending a mail is trivial, and code changes are text (most of the time), it can hardly be beat in simplicity. Anecdotally, most of our new hires from the last years had no experience with the email workflow, and a few weeks in most of them find it way better, while the rest finds it at least as good as the alternatives (and here they mean gitea or sourcehut, not the monsters that GitHub/Lab are).

ligurio 3y ago
> Configuring git send-email is trivial, definitively faster than creating an account at some web UI from a "source forge" <snipped>. You forgot that mailing list requires subscription and in some cases it could be a tricky. Without proper subscriptions and confirming subscription, your mails with patches will go to trash.
- severus_snape 3y ago
  There is usually no need to subscribe.
  - nolist_policy 3y ago
    This. You just To: the mailing-list and depending on the project CC: the maintainers. No subscribing needed. Standard policy on all mailing lists is to reply-to-all so you'll get always CC'ed on replies. This also makes it very easy to pull in more people into a discussion, even across different projects.

nicoco 3y ago

It's also possible to not be religious about it. Git is distributed. I have projects on srht and contributing does not mandate using the send-email workflow. "Push it somewhere and let me know where I can pull" always works too.

TotempaaltJ 3y ago

Hard agree! I think the success of Github's PR system over Git + email workflows has proved itself quite well through sheer adoption numbers.

tristan957 3y ago
The largest open-source software projects in the world don't use it though, so that tells me there is something lacking.
- bitcharmer 3y ago
  Maybe so, but my interpretation is that there's personal opposition to change and improvement from people like Linus or TGLX or other greybeards. At least in the linux kernel world. The contribution by email is an antiquated approach and needs to go. Now, knowing the HN crowd this comment will become grey in 3... 2... 1...
  - ungamedplayer 3y ago
    They say that scientific discovery advanced one death at a time. I imagine this same theory applies to kernel development tooling. I understand not changing for change sake. The kernel is at this time not "this gen" developer friendly.
  - tristan957 3y ago
    What is antiquated about sending patches via email? Have you ever used email to contribute to a project or review a patch?
    - atomicUpdate 3y ago
      Contributing patches via the Linux mailing lists is worse than Gerrit in every way.
      - tlamponi 3y ago

djha-skin 3y ago

> not only drive away a significant number of potential contributors, It drives away the kind of people who have little patience for technology problems and little patience for learning new things. I don't want those kind of people working on e.g. Git. Git needs people who have lots of patience for technology problems and lots of patience for learning new things.

tmpX7dMeXU 3y ago
Oh please. Lots of people, myself included, take issue with having to answer your riddles three before I may cross the bridge that you value much more than I do. There’s having patience and problem-solving ability, and there’s not seeing the value in jumping through the various hoops that comprise some ‘90s Internet fetishist’s playground. This is all just code for “I’m old, set in my ways, and don’t appreciate the fact that the only reason I find my workflow easier is because I know it, not because it’s more intuitive than what people are doing these days”.
fodkodrasz 3y ago
> It drives away the kind of people who have little patience for technology problems and little patience for learning new things. like learning to use a GUI and a Web Interface?
- scbrg 3y ago
  It's not really that people can't use them. It's that they're slow, annoying, hard/impossible to automate, hard/impossible to customize and give you RSI. We've seen Web interfaces, they're hard to avoid. We've just decided that they're worse.
  - fodkodrasz 3y ago
    Could you, for a moment, imagine that others might feel like that about the command-line-plain-text-email-to-mailing-list workflows? Possibly not, as you have labelled them > the kind of people who have little patience for technology problems and little patience for learning new things Also tell me how is tolerating rude incumbents of mailing list sending email with 50+ characters in a line a technical problem? (Yes they are often rude, and unwelcoming to those attempting to accept their anachronistic ways. You are demonstrating that specific behaviour right here, which many of us have encountered on those projects.) I think the projects which accept contributions only from mailing lists will have their contributors die out, or will be forced to change their ways to survive. I for one will never again attempt to contribute to such project, thanks to the inflexibility of the incumbents I have faced several times. Also thanks to the sub-par review workflow, usually the lacking quick CI feedback. Web UI might give you RSI, but the insufferable email-only-patches people give me PTSD from my previous encounters. ps: if you are willing to learn new things, you can automate web apps and GUI apps (eg. Autoit, xaut). Some even have proper APIs (COM/dbus/web api), or a cli!

sbjs 3y ago

There's a psychological basis for people taking pride in a difficult task learned and mastered, and many organizations take advantage of this by creating a culture that rewards this effort when put towards their own products with social status within the organization. It feels manipulative and unethical to me.

sbjs 3y ago
(Dare I say HN is one of them, where the effort is a curated form of elitism, and the mechanism up/down votes?)
carapace 3y ago
Like GitHub.

gwd 3y ago

Our project inherited a patchbomb-based workflow from Linux. Many of the individual members have also contributed to gitlab/hub based projects, and appreciated a lot of the automation available, as well as recognizing the lower barrier-to-entry of not having to figure out how to get an SMTP connection. So a few years ago we experimented with allowing "small" patches to be sent via PR on gitlab, and doing the review there. Basically, everyone agreed that actually doing the review on gitlab was a lot worse compared to email. There's just so much more flexibility. It's not off the table that we may give it a try again, because the advantages of having concrete pull requests (and issues and...) rather than patch series is pretty significant. But if you're familiar with doing email-based review, I think it's still a far superior; and you're definitely giving something up when you move away from it.

0xffff2 3y ago
>Basically, everyone agreed that actually doing the review on gitlab was a lot worse compared to email. There's just so much more flexibility. Could you elaborate? This is truly shocking to me. Admittedly I have never worked on a project with an email-based workflow, but I can't think of how email would allow comments inline with the patch, which is an incredibly beneficial feature to me.
- gwd 3y ago
  Well yeah, replying in-line to the patch to make comments is definitely a requirement. :-) You always reply with quotes; and you always reply inline, below the thing you're replying to. Quoted material is typically indicated by '>'. So for one thing, you can easily trim your reply to just the bits of the patch that you think is important; that makes it easy for anyone reading; you don't have to skip over large parts of the thread. Then you can also re-arrange what you're replying to, to make it make your reply make more sense. Furthermore, suppose A replies to the patch and makes comments 1, 2, and 3 (inline in a single email). When person B replies to A's email, they typically also send a single email, perhaps with replies 1' and 3' (trimming out comment 2, which they don't care about). This means if you've read A's mail, you can just read B's mail, and all the "new" comments are collected in one place (with the thing they're replying to). Contrast the above with gitlab, where A's replies 1, 2, and 3 are spread throughout the patch; and B's replies will also be spread out, meaning you have a kind of discoverability problem to see both 1' and 3'. And suppose in the course of talking about something you realize this bug may actually be a security issue -- you can remove the list, cc' "security@", and pick up the discussion without having to do any copy & paste. Same goes if you want to make a private comment, or bring something to someone's attention; just reply, remove everyone else, and say "FYI". I wish I had a really good recent example to show you, but a quick skim of today's threads isn't anything special. :-) I mean, I was arguing with people online [1] on BBS's in the early 90's, and I was on Usenet back when that was the main social network; so this "reply and comment inline" way of having a discussion is pretty well ingrained for me. But there are people on my team in their early 30's who also took to the email workflow really quickly too. [1] https://xkcd.com/386/ https://xkcd.com/386/

diogenes4 3y ago

> Organizations that insist on using workflows like git send-mail and mailing lists not only drive away a significant number of potential contributors, but they also form a weirdly religious culture that fetishizes needlessly painful process and is incapable of improvement You could say the same of GitHub. Why do I need an account on your lil site just to get a patch accepted?

grayhatter 3y ago

> Organizations that insist on using workflows like git send-mail and mailing lists not only drive away a significant number of potential contributor Often that's a bonus if not the whole point to begin with. The higher the barrier to entry the less noise you need to filter through. It only feels annoying to you because you're not used to it.

0xbadcafebee 3y ago

> workflows like git send-mail and mailing lists not only drive away a significant number of potential contributors A GitHub PR is way more steps than e-mailing a patch to a mailing list, and far less accessible. Have you never done the "sign the contributor license agreement and get the GitHub bot to approve it" polka? I've done it a dozen times now, it's painful and way more gatekeepery than just emailing a patch. > but they also form a weirdly religious culture that fetishizes needlessly painful process and is incapable of improvement Who hurt you?

carapace 3y ago

You went from "I find it inconvenient" to "they're masochistic cultists" pretty quickly there. Ad hominem attacks are against site policy. You've spawned a huge thread of people being incredibly self-righteous about the mind-boggling difficulty of sending email. It makes me think that it's actually a great filter to keep out people who prefer drama to clicking a few buttons that are different than the buttons they're used to clicking. I understand that familiarity is a powerful driving force in human psychology, but really, it's not like it's that hard to learn a different flow. I mean, I've had to use Perforce, and while it's fun to complain, it really wasn't that hard. I didn't even have to get out of my chair.

moritzwarhier 3y ago

The process tends to be a lot less painful when using git-combine-mailmap [1] ^1 https://git-man-page-generator.lokaltog.net/#Y29tYmluZSQkbWFpbG1hcA== https://git-man-page-generator.lokaltog.net/#Y29tYmluZSQkbWF...

wkz 3y ago

It's easy to forget the maintainers' side of this. Yes, most contributors will prefer opening a PR on GitHub as apposed to mailinglists. But imagine instead that you are David Miller, and it's your job to consume the absolute fire hose of patches and messages related to Linux's networking subsystem. Would you rather wade through the hundreds of messages and patches coming in every day using either GitHub PRs and issues or email? I would choose email for one simple reason: It's easier to script. Even as a small-time contributor and observer to that space, I couldn't even imagine trying to keep up with everything going on if I couldn't bulk download, filter, tag etc. As a maintainer it would be excruciating.

jeffybefffy519 3y ago
Github has an api for this…
- diggan 3y ago
  Which eventually will change, and you have to update everything. Or the company disappears and you have to move somewhere else. Email is just email. You write SMTP/IMAP clients today and they'll continue to work for a long time, probably longer than most platforms with APIs online today.
- wkz 3y ago
  And once you've used that API to download and tag everything, what tools do you use to interactively view the results, run search queries, apply patches to local trees etc? If your on-disk format is an Mbox or a Maildir, you can use tools like notmuch and its emacs integration to do it. Now don't get me wrong; I love GitHub. I host all my projects there, and I prefer PRs+issues to mailinglists in almost all cases. But for massive projects like Linux, a mailinglist (and associated tooling) scales better, in my opinion.
myaccountonhn 3y ago
It’s easier for contributors too, you don’t need an account.

myaccountonhn 3y ago

I personally self host git and think that email gives a bunch of advantages: 1. Email has clients with full offline support. Sometimes I work in locations where internet is bad to nonexistent and with github I am limited in what I can do. 2. Anyone can contribute to my repos without needing to sign up to my website. Git with email truly allows decentralization of “forges”. So in the same vain, I can contribute with the same client to any project on the web that accepts email patches and it’s the same workflow for all of them. 3. Since I have an email client for my email, I can set up my own custom workflow that is much faster. Github siloes you into a begrudgingly slow one. My email client integrates into my editor and gives me the same keyboard shortcuts I use to navigate my code. 4. Did I mention it removes centralization? Having github be the center for all repos makes it ripe for enshittification. Given Microsoft’s history for EEE, I don’t trust them one bit.