Having to sort through messages individually, not being able to browse code, no convenient links, no formatting, no branch visualizations, release notes being easily accessible, having to set up a bunch of fragile text based filters. It's just obviously a worse choice
> having to set up a bunch of fragile text based filters.
Why?
I see arguments like yours about email and git a lot. Why do you think people disagree with you? You have to pay attention to what you are really saying. You are not listing advantages of web-based git interfaces. You are listing "disadvantages" of existing tools. And all of the "disadvantages" you list are really areas where you do not understand how to use Unix programming tools effectively. Getting off of webmail and onto a good text-based email client is one of the best things you can do as a computer user.
Or rather --- the age of text-based email clients has really come and gone. The world has moved on. Web or GUI based PRs are accessible to all developers of many different levels and experiences, that is why they have (and will continue to) be the winners.
Once again, an opinion from someone who does not know how to use the tools effectively. The world has moved on, and left web-based email clients behind. If you haven't checked out what modern text-based email clients and IMAP syncing tools can do, you are really missing out. I switched from Gnus to Gmail in 2006, and switched from Gmail to mu4e/offlineimap last year. The comparison is not even close; mu4e/offlineimap is an overwhelmingly superior solution.
Negative. An opinion from someone who finds the value in GUIs despite knowing about the alternatives. Use what makes you productive, but for MOST people, that is going to be a well done GUI over a text based solution. For me, I don't want to spend time configuring or fixing my email solution, I just want to login, get/read/reply to my email, and move on to real work. Don't confuse your opinion with what is "best" or "most effective" for most people, even developers and those ultra-familiar with the terminal.
> Don't confuse your opinion with what is "best" or "most effective" for most people, even developers and those ultra-familiar with the terminal.
I am not stating an opinion. I am making a judgement. I can do that because I have the requisite knowledge and experience. You do not - as you yourself stated, you "don't want to spend time configuring or fixing [your] email solution." (another tell-tale sign is referring to "the terminal.") Stop trying to make virtue out of your choice to be ignorant. Stating that most people will prefer GUIs is not an argument for anything ("X is popular" is never a good argument for anything) - most people have not had any exposure to alternatives like text-based tools and therefore cannot have any meaningful or informed opinion on the matter, which you pretend to do. Your choice to be ignorant of something does not entitle you to make judgement calls about the things you are ignorant about. You can say "X is difficult to learn/do" (true), but when you argue that "X is an inferior tool" with someone that has some expertise in the subject and in X, you just come across as a fool.
Fyi: you come across as condescending and elitist. Not sure if that is what you are aiming for, but I don't think that's the best way to convince someone of your opinions.
I don't think the intent is to do code review from email. The idea would be to send the merge request through email, which is then imported into your local git as a branch. Then you're able to do review/analysis/etc with whichever git tooling you prefer.
You can still use a bug tracker with an email-based workflow. Many GNU projects use debbugs.gnu.org, which helps to keep track of patches that have been sent to the mailing list.
I can see how it would be inconvenient for people who use an inflexible email client or editor, though. (I'm trying to make this workflow a little less intimidating for Guix by working on a more convenient web interface on top of debbugs.)
I guess the question would be, what compelling reason would there be to do so? To me, the article's advantages are kinda meh, and I much prefer the tools provided in code review packages.
Do you mean the protocols, the clients, the servers, or something else?