6 ms·

> It shouldn't be an issue to install one. A somewhat related example I recently came across was when I had to install Google chrome to use a feature of Slack t

> It shouldn't be an issue to install one. A somewhat related example I recently came across was when I had to install Google chrome to use a feature of Slack that wasn't supported in Firefox. To get around that issue, I installed chrome. If I had to, I would have also had to set up the necessary proxy configuration for that browser to work (though that wasn't the actually the case). Firefox and Chrome are one-click setup, and the workflows are similar. Web based email is very different from local email. You need to decide a bunch of things on setup -- which folders do you want to sync? How does deletion work? The deletion model -- what happens when you delete a local message (and how to push local "deletions" to the server) -- is not at all obvious and confusing to configure. You get double notifications unless you configure that as well. Understand that people interact differently with email; so while it's easy to use web clients (and phone clients based on the web client which provide a uniform UI), matching your email provider's features and functionality with that of the MUA, and then working it into your personal workflow is tedious and confusing. GMail in particular behaves quite differently from what MUAs expect (labels are one example). Browsers on the other hand operate on largely the same model. Overall MUAs involve a significant change in workflow. You can of course set them up for "just patch mailing lists" and continue to use your existing workflow for everything else. I've done this, and it's super annoying, especially if you intend to contribute long term. Both I and a lot of folks I know tend to restrict themselves to the commandline+browser+optional editor, having a second place in a completely different app to deal with email for just one project is just not worth it. The issue with proxy configs is that proxy configs are often documented for browsers but can't always be set up the same way for MUAs, especially because SMTP is not an HTTP port and won't work without HTTP CONNECT tunneling with HTTP proxies (setting this up is horrible). And, again, port blocking. > I can say that I have a better user experience with the MUA compared to the web based front ends. I didn't say that MUAs aren't better, I said that you can handle things effectively with web based clients. This is not true of lynx, for example. This means that many potential contributors will never have used MUAs, but will have definitely used non-commandline browsers. > There are a number of steps one has to take to contribute to a project. Sure. And projects should strive to make these steps easier too. I have helped folks (not just new programmers, mind you) get involved in open source, and the rest of these steps are fine for them, but needed lots of help with the mail client setup for contributing to the mailing list. > It's easy enough to see whether or not ports are blocked by attempting to connect to the SMTP, POP/IMAP servers. Yes, but if ports are blocked, you're hosed. The question isn't if you can find out if ports are blocked, it's what to do when they are. Mail ports are blocked by many shared networks because it's easy for one malicious entity to start sending spam, getting the IP blacklisted, affecting legitimate email. It's sometimes possible that IMAPS (993) is open, but you need to know to look for that and try to use it. > I have never encountered an issue where I accidentally deleted all my email in the last 22 some years of using email while using my local MUA. Yes, but it's not obvious that this is the case, and that's where the confusion stems from. Folks will be afraid of using a tool that they think may potentially destroy their email. ------------- It really shouldn't be hard for a hybrid approach here. Have a mailing list with a web interface. A good one, with formatting for patches, and the ability to participate online with finer control over email. There shouldn't be web features that can't be used just as easily for those used to a mail interface. This still has the problem that you still need to copy patches, but it's much better than what's out there now. Github sort of already does this, but in the opposite direction -- it's a web based tool that you can interact with from the commandline (via hub) and email (in discussions). However, you can't do reviews from email (so the "no web features that can't be used from email" isn't true). Then again, I find email-based reviews to be very lacking compared to what can be done directly on github or the review tools folks integrate with it.

u801e 10y ago
> Firefox and Chrome are one-click setup Not necessarily. There are extensions to set up, proxies to set up if you're behind a firewall, etc. > [Local email] You need to decide a bunch of things on setup That may apply in a few special cases, but every time I set up Thunderbird or any other MUA, the only things I have to enter are the SMTP and IMAP servers along with my credentials. Thunderbird will even auto-detect those settings (other than one's credentials) for the more common set ups. Then it's just a matter of waiting for all the messages to download and populate the folders. Because of IMAP preserving the flags that I set on messages from my old client, the new client can already tell if I've read certain messages, marked them as important, etc. > The deletion model -- what happens when you delete a local message (and how to push local "deletions" to the server) -- is not at all obvious and confusing to configure. I've never had that problem using the default configuration that Thunderbird comes with for IMAP. When you delete a message, it's marked with the expunge flag, IIRC and will be deleted when you end the IMAP session. Some servers will allow you to recover those messages if you mistakenly delete them. If you're using POP (and not many people use that AFIAK, at least compared to IMAP), then there's an option as to whether to delete messages from the server when you download them. > Sure. And projects should strive to make these steps easier too. I have helped folks (not just new programmers, mind you) get involved in open source, and the rest of these steps are fine for them, but needed lots of help with the mail client setup for contributing to the mailing list. I think there's just a fundamental difference in opinion here. Many people, including myself, learned a lot of what they know by experimenting, reading documentation/articles, asking around, etc. They didn't need to have somoene guide them step-by-step in order to complete a task. They would read guides and then expand their knowledge based on what they read. > Yes, but if ports are blocked, you're hosed. In the case of email, that would just include port 25 which is unsecured SMTP. No one should be transmitting their credentials in plain text over an unsecured connection. Ports for secure transports (SMTP, IMAP, etc.) aren't typically blocked by residential ISPs. They may be blocked in a company's corporate network, but that doesn't mean they can't compose their messages at work and then send them off once they get home and can use their home network connection. > It really shouldn't be hard for a hybrid approach here. I agree. One can use git format-patch and git send-email to actually send patches to the email list (and CC any maintainers who wrote the code they're modifying). They can participate in a review discussion via their preferred way of accessing their email. If they need to post a follow up patch series, they will need to access the message-id of the original message (unless the idea of generating and retrieving the message-id I mentioned above is implemented) and use git format-patch and git send-email to send the follow up series. > Then again, I find email-based reviews to be very lacking compared to what can be done directly on github or the review tools folks integrate with it. I've found Github, in particular, to be rather lacking in terms of code review. For example, it has collapsed comments made on lines of code that happened to change, but not in a way related to the comments made on them. It doesn't have a way to thread comments (meaning that you cannot automatically associate a reply with its parent comment that happens to be several comments away from the most recent one made on a PR. There's no way to know whether your review has been addressed without having to scroll all over the PR page to find your comment (which may disappear if someone does a git force push to push up an amended commit or rebased branch). With email, it's pretty easy to see whether a thread has new messages, whether someone has replied to a message, or that there are messages you haven't replied to. Also, given the thread overview pane that a MUA has, it's far easier to have a more extensive discussion without requiring an excessive amount of scolling/paging. In a github PR, it starts to get rather unwieldy and require a lot of scrolling once you get beyond 10 to 15 comments. Some review tools like gerrit, phabricator, reviewboard, and others do address these issues to some degree, but they themselves take more time to learn, install and configure compared to an email client and configuring the git email related utilities.

u801e 10y ago

> Firefox and Chrome are one-click setup Not necessarily. There are extensions to set up, proxies to set up if you're behind a firewall, etc. > [Local email] You need to decide a bunch of things on setup That may apply in a few special cases, but every time I set up Thunderbird or any other MUA, the only things I have to enter are the SMTP and IMAP servers along with my credentials. Thunderbird will even auto-detect those settings (other than one's credentials) for the more common set ups. Then it's just a matter of waiting for all the messages to download and populate the folders. Because of IMAP preserving the flags that I set on messages from my old client, the new client can already tell if I've read certain messages, marked them as important, etc. > The deletion model -- what happens when you delete a local message (and how to push local "deletions" to the server) -- is not at all obvious and confusing to configure. I've never had that problem using the default configuration that Thunderbird comes with for IMAP. When you delete a message, it's marked with the expunge flag, IIRC and will be deleted when you end the IMAP session. Some servers will allow you to recover those messages if you mistakenly delete them. If you're using POP (and not many people use that AFIAK, at least compared to IMAP), then there's an option as to whether to delete messages from the server when you download them. > Sure. And projects should strive to make these steps easier too. I have helped folks (not just new programmers, mind you) get involved in open source, and the rest of these steps are fine for them, but needed lots of help with the mail client setup for contributing to the mailing list. I think there's just a fundamental difference in opinion here. Many people, including myself, learned a lot of what they know by experimenting, reading documentation/articles, asking around, etc. They didn't need to have somoene guide them step-by-step in order to complete a task. They would read guides and then expand their knowledge based on what they read. > Yes, but if ports are blocked, you're hosed. In the case of email, that would just include port 25 which is unsecured SMTP. No one should be transmitting their credentials in plain text over an unsecured connection. Ports for secure transports (SMTP, IMAP, etc.) aren't typically blocked by residential ISPs. They may be blocked in a company's corporate network, but that doesn't mean they can't compose their messages at work and then send them off once they get home and can use their home network connection. > It really shouldn't be hard for a hybrid approach here. I agree. One can use git format-patch and git send-email to actually send patches to the email list (and CC any maintainers who wrote the code they're modifying). They can participate in a review discussion via their preferred way of accessing their email. If they need to post a follow up patch series, they will need to access the message-id of the original message (unless the idea of generating and retrieving the message-id I mentioned above is implemented) and use git format-patch and git send-email to send the follow up series. > Then again, I find email-based reviews to be very lacking compared to what can be done directly on github or the review tools folks integrate with it. I've found Github, in particular, to be rather lacking in terms of code review. For example, it has collapsed comments made on lines of code that happened to change, but not in a way related to the comments made on them. It doesn't have a way to thread comments (meaning that you cannot automatically associate a reply with its parent comment that happens to be several comments away from the most recent one made on a PR. There's no way to know whether your review has been addressed without having to scroll all over the PR page to find your comment (which may disappear if someone does a git force push to push up an amended commit or rebased branch). With email, it's pretty easy to see whether a thread has new messages, whether someone has replied to a message, or that there are messages you haven't replied to. Also, given the thread overview pane that a MUA has, it's far easier to have a more extensive discussion without requiring an excessive amount of scolling/paging. In a github PR, it starts to get rather unwieldy and require a lot of scrolling once you get beyond 10 to 15 comments. Some review tools like gerrit, phabricator, reviewboard, and others do address these issues to some degree, but they themselves take more time to learn, install and configure compared to an email client and configuring the git email related utilities.