As a mailing-list bound software professional, this is wonderful news. Maybe one day we will be free of software development on MLs.
Compared to that any fancy service provides lock-in under thin veil of "friendly interface".
Now, there are strengths too. Like being archived easily & having threaded conversations integrated.
Pulling local trees has been absolutely better IMO with mailing list. I can literally with single keybinding apply patch to relevant repo, something that takes much longer route with Github. (convert URL to raw.github/whatever, copy and paste to apply, or do clicky-clicky in the Github app or whathaveyou)
Oh no, they are not. I loathe projects that only do mailing list support, because that means I have to subscribe to the mailing list, create a new folder and filter rule so that the mailing list doesn't flood my inbox with stuff I don't care about, and once the problem is solved, leave the mailing list, remove the filter and folder.
In contrast, issues on GitHub/GitLab or public self-hosted GitLab instances only require me signing up once (and in most cases via some form of SSO), I can add attachments such as screenshots or detailed logs that would just blow through the ridiculous size caps on mails, and I only get notifications on topics I explicitly subscribe for.
That's a workflow problem on your side. Why is it so hard? Maybe your mail user agent isn't configurable?
"In contrast,"... "me"... "I"... "I"... "I"...
Every one of your proposed advantages are not about the community's health, but about your convenience and ability to ignore the community as a whole.
It's fine that you have a preference, but claiming that your preference is more democratic is incorrect.
What makes a ML based workflow better for a community?
> It's fine that you have a preference, but claiming that your preference is more democratic is incorrect.
Most development is not done over MLs, that's a fact. The percentage of ML-based development done over time is shrinking. So I'd say the democratic vote is not one in favour of MLs.
You were talking about MLs being more barrier-free than "friendly interfaces". I showed why that is not the case. The effort required for dealing with MLs is way higher.
Anti-spam measures are a large part of what made using MLs so annoying. From a moderation side, MLs are more work for that reason as well - Github and Gitlab at least get rid of spambots shilling shady cryptocurrencies, weenie enlargeners or questionable quality designer drugs. With MLs, all of this ends up in your moderation queue as well.
All the relevant mailing lists for my interest projects have web interface/archive, I can selectively reply/participate in any or no ongoing threads, and stop at any time.
This is the same as saying we should only ever do open source development on closed proprietary platforms which only exist and allow access on the whim of a single entity which responds to no one.
As opposed to communicating over a completely open, decentralized and inherently free protocol.
Technically there are git based issue trackers and code review systems but that's unrelated note
- CI integration
- Rich markup, for images etc.
- Simple patch management
- Edits to messages
- Issue tracking
Rich markup: you can use HTML in mail. I think it's silly, but you can do that.
Simple patch management: that's what version control systems are for; if your vcs doesn't support email, you can't do that. If it does, you can.
Edits to messages: you mean altering the past? That's a terrible idea.
Issue tracking: that's what bug trackers are for. You add a link to the bug number, or, more likely, you send a mail message to the bug tracker's email interface and get a bug number back. Send more email with the bug number in the subject and it gets added as a comment to the bug.