Some people have called out git send-email as being difficult for new programmers to get the hang of. I usually respond to this by pointing out that the speaker didn't always know how to use GitHub, too - and as someone who often reviews pull requests from new GitHub users, that workflow is confusing and takes time to learn, too.
But, this notion was disproved another way: someone just sent me a perfectly formatted patchset via the git.sr.ht patchset submission UI, with no hands-on instruction, and told me later that it was their first-ever contribution to free and open source software.
@sir My first contribution to a FOSS project (that wasn't my own) was similar. Once you get your git config right, git send-email just works, it's amazing how easy it is. My contribution (to Sourcehut too) may have just been a little trivial thing, but it felt great being able to contribute without needing to go through a website.
Then more recently I got my first experience receiving patches via email and it was an equally pleasant experience.
Git(Hub|Lab) etc just make the process needlessly complicated
@reto @OTheB @zem the mailing lists make this fairly straightforward and archive the discussion. The archive is also distributed among all subscribers to the list, which removes the single point of failure. There are other practical problems with the GitHub model, but I they probably deserve a blog post
@OTheB @sir whilst I agree conceptually, the thing that breaks it is that email which was originally designed for a much smaller network with different barriers to entry does not work the same way any more. SPF, dkim and alike mean that email sent from a random pc is most likely blackholed. More of a problem with the underlying carrier than the implementation, but one that is a fairly big issue with the workflow imo.
@sir @OTheB strongly disagree, to set up an email server correctly (and bear in mind that a lot of individuals are on USPS that block outbound port 25 for VERY good reasons) you have to understand a lot more than installing git and pointing it at a "forge" and clicking through the sometimes confusing flow of a pull/merge request. Firewalls, DNS, what is SPF, who runs these blacklists, how do I get a TLS certificate, debugging systems you only see half of, etc.
In any case, setting up your own mail server is not necessary for anyone to contribute. There are thousands of mail providers out there. Even if you rely on someone else for your mail, the federated, distributed system of email is better than the centralized system of pull requests in most respects.
And if you anonymize your shit, your patches are getting rejected. Anonymity harms accountability. Chill tf out with your special snowflakeness yo
Just chiming in to note that I've been running a mail server for 15 years or so and I still don't have it configured right for GMail to reliably not send our messages into the spam folder, and Microsoft tends to drop them into /dev/null.
So, no, not overstated. Some people don't have time to keep up with every new anti-spam protocol because we're struggling just trying to keep everything working on a basic level.
It looks like I'm still missing a couple of things, starting with DMARC. I spent about 20 minutes trying to get it set up, just now, but can't get the DNS record to save; it says "something went wrong", with no further info.
My email to Microsoft (outlook.com) is no longer being dropped silently, so I must have done something right the last time I messed with this stuff (I think I set up SPF), but it's still being delivered to the Spam folder by default.
My point stands: this is nontrivial stuff.
Thanks for the mail-tester link, though -- it does many more tests than the one I was using. (I did get a 9 out of 10 score for the domain I tested, so I've got it *mostly* right.)
@sir @OTheB to add perspective, my day job is running systems like this, and all my personal stuff (WebDAV, blog, peertube etc.) is self hosted, except I pay for email hosting because it's a nightmare to manage. I have the skills but it's not worth the time and stress for something that's pretty essential to be running 24/7.
@sir @OTheB okay, so you know why end users sending email from their local machines (if port 25 isn't blocked) is at best a bad idea then, and how to avoid that they need a forwarding server locally which if they don't get that right, they end up as an open relay, and might get their entire connection blocked, and that's "simpler"? I don't disagree that a distributed system would be fantastic (looking forward to #forgefed myself) but git-send-email imo is flawed.
@sir @OTheB okay, reading your page clears up a lot. git-send-email is a total exception to how email generally happens on Linux, bsd etc. with cli tools, usually there is no chance of configuration of the tool, much less the option of SMTP+TLS. I still think that PRs in a forge system are acceptable and especially with #forgefed things get better, but I'm gonna retract my main objections against git-send-email.
@sir wait a minute... Are you saying someone _read the docs_ and followed instructions?
I don't know if I can believe something so outlandish.
@stick it puts a tear in my eye
@sir The patchset submission UI makes that significantly easier. I would be skeptical if the comparison was between GitHub and git send-email directly, but... yeah, git.sr.ht makes it seem reasonably approachable IMO.
@sir Is there a plan to provide commands for configuring sendemail in a repo to work as expected in the sourcehut ui? I mean the git config variables sendemail.to and format.subjectPrefix mostly. Or is that what a maintainer should put into the readme?
@pea hehe don't get me started
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!