Ciro Santilli @cirosantilli  40

no metadata, notably the notion of closing / merging, but also upvotes

You have to read thirty messages before you can know if the bug was solved or not.

it is insanely hard to reply to messages from before you were subscribed: webapps.stackexchange.com/questions/23197/reply-to-mailman-archived-message/115088#115088

This forces everyone to subscribe to all lists, and then set up email filters to not be flooded with emails.

hard to apply patches locally to test them out: stackoverflow.com/questions/5062389/how-to-use-git-am-to-apply-patches-from-email-messages/49082916#49082916

Unless they use Patchwork, which adds one more website on top of the mess.

And then Gmail corrupts your patches, and you are forced to use git send-email, which does not work on some network configurations: stackoverflow.com/questions/28038662/how-to-solve-unable-to-initialize-smtp-properly-when-using-using-git-send-ema or setup ThunderBird.

you can edit posts to make them clearer.

Yes, people could vandalize their answers when they get mad, and threads might stop making sense after edits. But this can be solved with an undeletable post history like Stack Overflow has (but not any other tracker does).

Or archive.org :-)

In any case, what do you think will happen more often and have greater impact:

searchable by author, keyword, etc. without Google. Yes, mailing list trackers could have decent implementations to overcome that. But no, GNU Mailman which everyone uses does not have it. Google barely indexes it.

And I don't think Google properly indexes many of the mailing list archives for some reason: I never get hits for my own posts a week later, while I often do on GitHub issues.

Line comments in code reviews like GitHub and GitLab.

On mailing lists: either put a comment in the middle of a huge patch and let other people find it, or (more likely) copy paste the part of the patch that you are talking about.

most mail web UIs suck.

OK, this is not an unsolvable or intrinsic problem, but still a problem.

E.g.: ezmlm it is not possible to see the entire content in a single page: gcc.gnu.org/ml/gcc/2015-07/threads.html.

Unless you like reading threads backwards and with 4 levels of > quotations.

The alternative: do like LLVM and send attachments. Yes, I we all love opening up attachments on our browsers.

The real solution: everyone can create branches and pull requests. Also has the benefit of running CI on the pull requests.

you can have infinitely many trackers to replicate data in case apocalypse happens in some part of the world.

Although I'm not sure this is an advantage, as you don't know anymore which one is the canonical trackers an advantage, as you don't know anymore which one is the canonical tracker.

And all web interfaces already have an API to export messages, and someone has already scripted it to import from any web UI to any web UI for you.

And GitHub offers infinite precise history transparently on its API.