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).
> 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.
In what cases is it tricky? I find that most projects use some version of mailman (like QEMU - https://lists.nongnu.org/mailman/listinfo/qemu-trivial) and then it's just a question of filling out the form and hitting "Subscribe". I cannot remember project I wanted to contribute to, I had to use git+email and it was difficult to subscribe to the mailing list they want me to use.
That’s because Microsoft GitHub is a proprietary monolith. Compare that to the open core & self-hosting of GitLab the more FOSS-positive space where each server (without federation) requires a new sign up, confirmation emails (meaning you already had to go thru email), CAPTCHAs, setting up new keys, etc. That said, you will need to get your email filters in place or you can get a lot of new, unwanted mail (assuming you are required to sign up which often isn’t the case).
Personally, it's not. I'm using GitHub and I also sometimes send patches in emails.
I'm asking specifically what part of subscribing to mailing lists is the tricky part, as that's what parent mentioned. I'm not saying it's easier/harder than GitHub's workflow.
And then every so often mailman hits you up with "I'm receiving all these bounces from your email server!" because all the various garbage anti-spam techniques were not quite thought out with mailing lists in mind or people have lots of misconfigured servers and servers with different acceptance criteria, and it's all a big mess.
Configuring git send-email is only half the battle, anyway - chances are you want to participate in the discussion of your patch, so better figure out how to make sure your email client will not send the forbidden HTML email.
This sounds like hyperbolic brought on by dislike, not a real indicator of time cost/effort. You've already spent more time complaining, than the work done to do these things!
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.
Many mailing lists today reject posts from non-subscribers.
Of those that allow posts from non-subscribers, you will find that many are configured such that you will not get a reply, due to "reply-to munging". Your message will go to the list, but with a Reply-to: header designating that list, instead of (or in addition to) setting the more modern mailing-list-related headers.
Reply-to-all isn't a list policy; it's a behavior of the individuals. Some people don't reply to all. They think they are, but only the post author gets their reply. That is one of the motivations behind the Reply-to.
The CC part is highly conflicted. Most maintainers hate double emails, whilst some loudly insist to be CC'd, esp. the Linux kernel folks. So you need to read beforehand the preferred etiquette.
And nevertheless, the tone on mailinglists is entirely different (and mostly extremely childish and unprofessional) than on ticket trackers.
There's complexity and then there's complexity. Your end user experience as a Discord user may be simpler on its face, but it's reliant on a lot of obfuscated complexity under the hood. You wouldn't be able to, say, send Discord messages using telnet, the way you can with IRC. Discord's simplicity in setting up an account, joining servers, having scrollback, etc comes at the cost of other types of simplicity.
People in this thread are talking past each other without realizing that they are expressing different preferences about where complexity belongs in a tool.
(For the record, I happen to be on the IRC / git mailing list side of the spectrum.)
Again, friction and velocity of what? It's a lot easier for me to write an IRC bot than a Discord bot. But other things are much harder to do with IRC. People are looking at different vectors.
That's surely hyperbole. You can just say "This is unnecessary" and it achieves the same purpose. Maximalist comments like this tend to amplify the tension in these sorts of discussions.
Clicking a link to open a chatroom directly, with no account creation process, is infinitely simpler than account creation, potentially with several layers of verification (CAPTCHA, email, phone verification to join a server...).
The linked article is literally a multi-step process of arcane terminal commands that differ by operating system. You may think it's easy, but it's definitionally not trivial.
Multistep is fair, though for the record "multi" in this case means 2. One of those steps (the only thing that differs by OS) is installing git- I think you'd agree that gatekeeping by ability to install git is pretty reasonable for a project that uses git. Using git send-email doesn't require much more configuration than configuring ssh keys to push to GitHub. The fact is, most open source development workflows outside the safe confines of java on intellij will rely on the ability to use a few commands. We're better off making more great documentation like this to help new people adjust than deliberately clipping their wings.
I have absolutely no desire to send all of my companies intellectual property to a mail server. It could be the best workflow in the world, but if one email address gets breached, you're leaking everything and that's really unacceptable.
Yes, you can transmit messages via SMTP using TLS, but you don't need any special tools to read the email once it's reached its destination which is the point you seem to be missing. And before you scream PGP, almost nobody uses it.
But that's exactly the same as anything else; you move git commits that you store locally (either encrypted or not) over an connection that's encrypted in transit (whether SMTP/TLS, HTTP/TLS, or git/SSH) to a remote server that stores the repo/commits (either encrypted or not). None of this is different depending on whether the remote is a mail server or github (or whatever).
TLS secures your message till the endpoint which is a (plaintext) code repo. Why would you want a special tool to read plaintext code? Your argument makes no sense whatsoever.
I’m not sure what you’re getting at here but it sounds more like an irrational hatred of email than something genuinely technical to me.
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).