Item — HN Reader

How exactly does mailing list contributions work? I've only ever seen a few urls of messages but they are extremely obtuse. You would need to click parent parent parent to get context on the message you originally read.

I must be missing something and since mailing lists are dying, would love to understand this relic of the past.

4 comments

Simple: you don't use the browser at all. You download the source code via your VCS client. You find the thing you want to change, make a branch, modify it, generate a patch. You email the list with your patch and a very detailed description of what you're doing and why. Lots of people reply, and your email client shows you the threads hierarchically. It makes sense to you because you started the whole conversation and see their in-line replies in your email client.

As an old fogey who started with mailing lists, and still uses them to send patches, it's actually much simpler than browser-based workflows. Most of it is your own workflow in your own repo clone in your own environment. The patch and email threads are a universal abstraction; you add the rest yourself, with any method you're familiar with. This removes any complexity that would otherwise be imposed by the browser, remote web app, etc. It's like sending someone a letter in the mail, rather than choosing between 15 different messaging systems, protocols, apps, OSes, etc. If you can read words you can figure out your own way to deal with the contents.

And as far as it dying out: I actually think it's faster to communicate via mailing list. The thing a GitHub clone gets you is co-located collaboration, and CI tests. Those things are very powerful, and really should be integrated into a single open source standard, rather than a lot of custom web apps. But the modern software developer doesn't understand the value of standards.

You're supposed to use a proper email client which solves this problem. Sourcehut uses the email contribution workflow and has the documentation to support it; have a look at it:

https://man.sr.ht/git.sr.ht/#sending-patches-upstream

https://git-send-email.io/

https://git-am.io/

Thanks for the links!

Seems you have to remember what -v you are sending as you respond to feedback. Pretty troublesome... Glad ffmpeg is moving to a more modern solution.

The web view is meant to be the publicly searchable archive, not the primary interface. Developers are supposed to use an email client and git integrations. You can follow a number of different guides to get set up to contribute but it’s not actually easy to use the workflows.

To be honest I think the difficult and learning curve is part of the goal. The people who operate in these worlds don’t want it to be easy for anyone to come along and get involved. One of the main objections to moving to hosted platforms like GitHub or Forgejo is from people who worry it will result in a lot of low quality PRs that have to be dealt with. I’m not suggesting I agree, but it comes up a lot.

> To be honest I think the difficult and learning curve is part of the goal. The people who operate in these worlds don’t want it to be easy for anyone to come along and get involved.

If you’re using the git tool, it’s very easy to get it working and easier to use afterwards. It allows you to use you own environment and not someone else’ web app. If you’re the maintainer, people send you patch and you can script out the review phase. If you’re a contributor, it’s actually a few command to send a patch to anyone. And learning how to cleanup your commits is always good.

I can understand the pain if your only email account is gmail. But there are good smtp providers out there.

Linux kernel today is still managed with patches on the mailing list. It shouldn't be hard to see how this can be extremely effective for a maintainer running a programmable editor like Emacs or Vim.