[ligurio]

> 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.

[diggan]

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.

[IshKebab]

How is that harder than signing up to Github?

[zanecodes]

I only have to sign up to Github once, not once per project.

[toastal]

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).

[diggan]

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.

[wodenokoto]

I think you meant “how is signing up for GitHub harder than that?”

[IshKebab]

Oops yes.

[stefan_]

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.

[b112]

That's a battle??

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!

[severus_snape]

There is usually no need to subscribe.

[nolist_policy]

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.

[kazinator]

That's how mailing lists should work.

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.

https://marc.merlins.org/netrants/reply-to-still-harmful.htm...

[rurban]

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.