4 ms·

> I don't see having to install and configure an MUA any more of a barrier to contributing than it is to install a web browser to use Github to contribute to ot

> I don't see having to install and configure an MUA any more of a barrier to contributing than it is to install a web browser to use Github to contribute to other projects that expect pull requests. Almost everyone has a web browser installed. Not everyone has a MUA installed. > 5. Use git format-patch to generate a new patch series for re-roll with a command line parameter that refers to the file containing the cover letter for the original patch series. This was the step I missed, thanks. This could work. You now need to keep your patches around, but it could work. > The sha1 of the commit should be unique enough. I meant stable across local changes to the commit. I didn't realize you were serializing this commit hash to some file and fetching it from the file later. > I disagree. It's not fundamentally harder to use a MUA, news reader, or IRC client than it is to use a web browser. I believe more people have a web browser set up than they do a MUA. You cannot browse the web effectively without a web browser (I mean, you can use lynx, but the modern web is not well suited for that), and this is pretty necessary these days. You can use email effectively without a local email client, however. It's not just that the MUA is harder to set up, it's that you're asking people to effectively change their entire workflow for interacting with email just so that they can contribute. And yes, MUAs are harder to set up. Refer to aforementioned points about blocked ports, confusing IMAP/POP3 deletion semantics (I don't want to accidentally delete all my email!), proxies, etc.

u801e 10y ago
> Almost everyone has a web browser installed. Not everyone has a MUA installed. 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). Similarly, if one wants to contribute to a project that requires emailed patch files, then part of the process should be installing and setting up a MUA if the web based front-end doesn't work properly. > This was the step I missed, thanks. This could work. You now need to keep your patches around, but it could work. I think it's easier than having to retrieve the original message via IMAP, POP, or HTTP and copying its message-id value :) > I meant stable across local changes to the commit. I didn't realize you were serializing this commit hash to some file and fetching it from the file later. Typically, when contributors do a re-roll of a patch set, they effectively either use git commit --amend or git rebase to update the commits in the branch they're working on. The updated patchset is sent to the mailing list and pulled down by reviewers and applied to their working tree (which results in a commit with the same change, but a different SHA1). This is unlike the case where one runs git fetch or git pull and pulls down the commits and gets the commits with the same SHA1 applied to their local copy. In other words, the SHA1 value isn't that important other than to serve as a unique value of the message-id header. > You can use email effectively without a local email client, however. I use both web based clients (hotmail, gmail) and a locally installed MUA (thunderbird). I can say that I have a better user experience with the MUA compared to the web based front ends. For the purposes of patch submission, reviewing, etc, I think that web based clients are really not sufficient due to the lack of threading (as I would see it in a traditional email client). > it's that you're asking people to effectively change their entire workflow for interacting with email just so that they can contribute. There are a number of steps one has to take to contribute to a project. Reading documentation, installing the software, documenting the bug they're proposing to fix, discussing the approach with project maintainers, implementing the change, testing the change, submitting the fix, responding to reviews, etc. Just submitting the patch is a small part of the overall process. For example, a contributer would have to set up the development environment such that they can run the tests that come with the project. That in itself could be a bit more work than figuring out how to use git send-email to submit the patches. > MUAs are harder to set up. Refer to aforementioned points about blocked ports, confusing IMAP/POP3 deletion semantics It's easy enough to see whether or not ports are blocked by attempting to connect to the SMTP, POP/IMAP servers. As for the "confusing [...] deletion semantics", 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.
- Manishearth 10y ago
  > 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

> Almost everyone has a web browser installed. Not everyone has a MUA installed. 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). Similarly, if one wants to contribute to a project that requires emailed patch files, then part of the process should be installing and setting up a MUA if the web based front-end doesn't work properly. > This was the step I missed, thanks. This could work. You now need to keep your patches around, but it could work. I think it's easier than having to retrieve the original message via IMAP, POP, or HTTP and copying its message-id value :) > I meant stable across local changes to the commit. I didn't realize you were serializing this commit hash to some file and fetching it from the file later. Typically, when contributors do a re-roll of a patch set, they effectively either use git commit --amend or git rebase to update the commits in the branch they're working on. The updated patchset is sent to the mailing list and pulled down by reviewers and applied to their working tree (which results in a commit with the same change, but a different SHA1). This is unlike the case where one runs git fetch or git pull and pulls down the commits and gets the commits with the same SHA1 applied to their local copy. In other words, the SHA1 value isn't that important other than to serve as a unique value of the message-id header. > You can use email effectively without a local email client, however. I use both web based clients (hotmail, gmail) and a locally installed MUA (thunderbird). I can say that I have a better user experience with the MUA compared to the web based front ends. For the purposes of patch submission, reviewing, etc, I think that web based clients are really not sufficient due to the lack of threading (as I would see it in a traditional email client). > it's that you're asking people to effectively change their entire workflow for interacting with email just so that they can contribute. There are a number of steps one has to take to contribute to a project. Reading documentation, installing the software, documenting the bug they're proposing to fix, discussing the approach with project maintainers, implementing the change, testing the change, submitting the fix, responding to reviews, etc. Just submitting the patch is a small part of the overall process. For example, a contributer would have to set up the development environment such that they can run the tests that come with the project. That in itself could be a bit more work than figuring out how to use git send-email to submit the patches. > MUAs are harder to set up. Refer to aforementioned points about blocked ports, confusing IMAP/POP3 deletion semantics It's easy enough to see whether or not ports are blocked by attempting to connect to the SMTP, POP/IMAP servers. As for the "confusing [...] deletion semantics", 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.

Manishearth 10y ago
> 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.