Hacker News new | past | comments | ask | show | jobs | submit login

Anything is better then e-mail based systems.

The discoverability, browsability, and useability of something with actual markup and design is infinitely better then e-mail.

I've tried several times to make submissions to several e-mail based projects, never with any success. At the same time, I've had zero issues contributing to a dozen or so github hosted projects.

E-mail systems are a shitshow. First, you generally have to join a mailing list, which is regularly broken, or requires someone somewhere to manually acknowledge your membership. Then, you have to figure out how they want shit formatted, figure out how to generate a diff (I've been using SVN for 8+ years, git for ~3 years, and have never had to deal with diff files!), send an e-mail, find the mailing list shat itself and troubleshoot, try again, etc....

Basically, e-mail is the death of any sort of low-effort contribution. If you're starting a new project, and chose a mailing list, you're probably excluding a huge quantity of potential contributors.

If there's a project where I want to make a few-line change or minor enhancement, and it's on github, I'll generally PR it back into the original. If it's somewhere else, or requires another account, there's no way I'm going to spend the effort.

Plus, just reading mailing lists is a fucking disaster. Literally no mailing list host I know of lets you just view a complete topic thread in simple chronological order on ONE PAGE. They all operate on a per-message response-tree structure, so just reading the discussion is a huge pain in the ass.

E-mail is basically dying among younger people, including the ones that code, and with good reason. For actual forum-type discussions, it's a completely shit solution.




> I've tried several times to make submissions to several e-mail based projects, never with any success.

$ git send-email --to=<mailing list> <commit range to send>

That was hard.

> First, you generally have to join a mailing list, which is regularly broken, or requires someone somewhere to manually acknowledge your membership.

Most public MLs that accept patches are Cc'd for posterity's sake, and thus generally don't require being a member to post. You will always get Cc'd to discussions (git send-email automatically adds you to the Cc list).

> Then, you have to figure out how they want shit formatted, figure out how to generate a diff [...], send an e-mail, find the mailing list shat itself and troubleshoot, try again, etc....

See above. It's one command, or two (git format-patch + send-email) if you want to tweak the email.

> (I've been using SVN for 8+ years, git for ~3 years, and have never had to deal with diff files!)

I find this hard to believe. You've never hand-edited a diff file with `git add -p` or `git checkout -p` -- or even done a `git diff`, `git show` or `git log -p`? I did all of the above things just today, let alone in the past three years...

> If it's somewhere else, or requires another account, there's no way I'm going to spend the effort.

I'm going to be honest, as someone who maintains a project hosted on GitHub I don't like it when someone decides they'll "help out" by dropping three lines of code in a patch and disappearing off the face of the earth. If you're not bothered to follow up on your patch review, then you've just inflicted a net negative on the project.

> Literally no mailing list host I know of lets you just view a complete topic thread in simple chronological order on ONE PAGE.

But chronological order isn't what you want for ML threads. You want to read it as a tree, because that's how people use email... Patch review isn't like a YouTube comment thread.


> $ git send-email --to=<mailing list> <commit range to send> > > That was hard.

So how the hell does that work?

Like, how does git know how to send e-mail? Do I have to stick smtp creds in somewhere?

> I find this hard to believe. You've never hand-edited a diff file with `git add -p` or `git checkout -p` -- or even done a `git diff`, `git show` or `git log -p`? I did all of the above things just today, let alone in the past three years...

There are many, many ways to interact with git, such as the many, many tools that make it so you don't have to interact with all that shit. tortoisegit is a wonderful tool, and it makes git SO much nicer.

> But chronological order isn't what you want for ML threads. You want to read it as a tree, because that's how people use email... Patch review isn't like a YouTube comment thread.

Except generally, before I'd interact with a ML, I want to see what the ML is like, and having to click through many, many pages with little content on each is just dumb.

Also, you may use e-mail as a tree, but that's you. I use thunderbird, and you can set it to display as a tree, or you can set it to not, and I personally don't.

As far as I can tell, 99% of the ML content I've read is basically a shitty, shitty implementation of a simple forum on a much crapper transport.


> As far as I can tell, 99% of the ML content I've read is basically a shitty, shitty implementation of a simple forum on a much crapper transport.

And when Github goes belly up, or whatever the SaaS version control flavor of the month is, mailing lists and their archives will still be there.

Simplicity is the ultimate sophistication.


And they will still be shit, until it's too hard to find anyone to collaborate on your projects.


> > $ git send-email --to=<mailing list> <commit range to send>

> > That was hard.

> So how the hell does that work?

> Like, how does git know how to send e-mail? Do I have to stick smtp creds in somewhere?

git send-email implements SMTP. You can give it your credentials directly using git config, or by using sendmail which quite a few people have set up (I use esmtp which is an implementation of sendmail that is very simplistic and just requires a password, server and username). And it all "just works".

> As far as I can tell, 99% of the ML content I've read is basically a shitty, shitty implementation of a simple forum on a much crapper transport.

Except forums are shit if you want to have different discussions about four somewhat-related patches. How do you handle trees of discussion like that?

> Also, you may use e-mail as a tree, but that's you. I use thunderbird, and you can set it to display as a tree, or you can set it to not, and I personally don't.

I don't use it as a tree when answering normal emails, but if you're Cc'd to three different discussions in the same thread it's much nicer to be able to see WTF the person above was responding to with better granularity than "something said on this mailing list at some point in the past".


> Except forums are shit if you want to have different discussions about four somewhat-related patches. How do you handle trees of discussion like that?

You're literally typing this into a forum that supports that kind of tree of discussion, and you're literally having a side-conversation right now. A web forum can implement any style of conversation you can conceive; the web's very generic that way.

I think GitHub deliberately doesn't support that kind of thing because they want to encourage having lots of little issues instead of a few big ones. It does get annoying for pull requests, though...


You can add send-email configuration in your .gitconfig. Here is an example from the documentation that uses gmail. https://git-scm.com/docs/git-send-email#_use_gmail_as_the_sm...


> $ git send-email --to=<mailing list> <commit range to send>

> That was hard.

What does this do by default in Windows?

In Linux, what if you don't have a local MTA installed/configured? I'd wager most GMail users aren't going to set up Mutt and an application specific password to make it all work.


You can configure it with SMTP, so it's usable with or without a local MTA.

Buuuuuuuuuut, that's still more effort than I'd be comfortable imposing on a new contributor, honestly. Guess why the kernel community keeps pushing away drive-bys?


The Eudyptula Challenge was my first exposure to git-send-email. My first email was rejected due to the attachment being base64 encoded, I think. This is how I know setting up Mutt with GMail is fairly painful.

I kinda get why LKML pushes away drive by contributions - if the quality of the patch is low it can cause problems for maintainers and subsystem maintainers. The kernel has stuff like checkpatch.pl to help though. If you're contributing to the kernel you should probably be able to run a Perl script.


> Guess why the kernel community keeps pushing away drive-bys?

Because drive-by contributions to the kernel are likely to be more trouble than they're worth? This is code which will run on every Linux device out there, from thermostats to WiFi access points to individual computers to Google's & Facebook's data centres: it had better come from someone who knows his stuff, inside & out, and it's probably a Good Thing™ if he's not afraid of a command line and email.


If you don't have a local SMTP setup (MTA is sth else): obtain your patch from your VCS (e.g. git diff revs...), save it to a file, attach to the mail via your mail client.


No need to git diff. Git format-patch does the work for you. Apply the patch with git apply-patch. Less work than sending a PR and the receiver has to do less work to merge locally in a branch should they want to modify something. Github does make it easy for drive by commits for typos an trivial changes like that.


> But chronological order isn't what you want for ML threads. You want to read it as a tree, because that's how people use email... Patch review isn't like a YouTube comment thread.

If any of them can display all of the tree on one page, then maybe I won't hate mailing lists so much. I hate clicking back and forth in a swath of emails, each having a little and often irrelevant content, and getting lost in where I am in this "tree".


> That was hard.

Yes, it was. I need to set up command-line email locally on my computer. How do I do this on Windows? (or, on Linux, for that matter) How do I do this if behind a proxy? What if port 25 is blocked entirely (i.e. many university networks)? I have been in at least one of these three situations for very long periods of time, each.

Of course, I can just format-patch + email, if I don't want to set this up locally.

Wait, no, I can't. Gmail replaces tabs with spaces in plaintext emails. Most MLs want plaintext emails. I could use an attachment but not all patch submission processes allow that. So I'm back to needing a client or switching my email provider. Welp.

Okay, let's say I managed to get git send-email working locally. Now, how do I send my updated patch after having gotten review?

Oh, I see, I need to muck with a Message-ID header. Looking at the first Google result (what most folks trying this will hit) http://studioidefix.com/2014/06/17/replying-to-lkml/ -- it's literally building the email headers from the command line, after some manual copypasting. There may be tools for this, but they're definitely not discoverable.

I could sync up my email client via POP or IMAP, but now I have to emails locally, and possibly change how I interact with email. Also, this is another bundle of confusingness. When I first set this up many years ago I synced a bit more than I needed, but was afraid of deleting things because the deletion may be reflected. Getting this set up just right is a whole other world of pain.

Nope.

Github isn't as easy as those used to it think either, but emailing patches is definitely not easy.

I've done a lot of mentoring for folks getting involved in open source. Like I said, it becomes apparent that GitHub isn't as easy as folks think it is. But it's well documented, and still not hard to ramp up on. I've had folks nearly give up on mailing list contributions.

> You've never hand-edited a diff file with `git add -p` or `git checkout -p` -- or even done a `git diff`, `git show` or `git log -p`? I

People interact with tools differently. GUIs exist. Interacting with diffs is different from interacting with diff files. I've got my `git diff` setup to show a much cleaner colorful diff (except when piped, in which case it shows a diff file). The only time I see normal diff files is when I'm submitting patches to MLs, (or when I'm copying patches across vendored repos; a niche task) the rest of my diff-viewing is with colorful commandline diffs that look quite different. It's easy for me to imagine that folks using GUIs would never directly deal with a diff file.

> because that's how people use email...

No that's how you use email. Others may not. Reading flattened comment threads is totally fine, even if the underlying review is treelike. Treelike viewing is more suited for viewing updates to a conversation you're otherwise caught up on, but often it's better to view a conversation you haven't seen before in a linear fashion.


> Yes, it was. I need to set up command-line email locally on my computer. How do I do this on Windows? (or, on Linux, for that matter)

All of those questions are answered in the man page for git send-email. You can specify them via a command line option when invoking that command, or just add that information to the git config file.

> Wait, no, I can't. Gmail replaces tabs with spaces in plaintext emails.

Is that done by the Gmail web client or is it something done by their SMTP server?

> Oh, I see, I need to muck with a Message-ID header.

One thing that I think would be an improvement to git format-patch and git send-email is having it default to setting the Message-Id header in the email it generates rather than relying on the SMTP server to generate it.

> but often it's better to view a conversation you haven't seen before in a linear fashion.

How do you deal with the case when multiple discussion threads are interleaved with each other? Is it easy to find the email that was partially quoted the message you're viewing?


> All of those questions are answered in the man page for git send-email. You can specify them via a command line option when invoking that command, or just add that information to the git config file.

Many, many pages below in the configuration section.

Yes, on its own that's not too big a deal (you can always google the setup, though for me it's the fourth result on google that is not the man page itself). But this stacks up with the rest of the issues -- with send-email it's tricky to respond to existing review threads with new patches. Clients fix that, but they have a whole host of other issues.

> Is that done by the Gmail web client or is it something done by their SMTP server?

The web client. Whether or not SMTP does this isn't the point here -- I brought up the web client as an alternative to using SMTP, because SMTP is not an option for many, and even if it is, one really shouldn't have to set up an email client and potentially change their email workflow to contribute patches.

> One thing that I think would be an improvement to git format-patch and git send-email is having it default to setting the Message-Id header in the email it generates rather than relying on the SMTP server to generate it.

That doesn't make sense, it doesn't know what message id to set. It needs to hook in to a mail client to know that.

> How do you deal with the case when multiple discussion threads are interleaved with each other? Is it easy to find the email that was partially quoted the message you're viewing?

I meant chronological view for a given thread. You still need fully threaded view, but comprehending an entire thread in non-inlined fully-threaded view is really annoying. Inlining the emails or using some JS for expand/collapse can help, but as it stands most if not all web interfaces for MLs are terrible.


>> Is that done by the Gmail web client or is it something done by their SMTP server?

> The web client. Whether or not SMTP does this isn't the point here

If I happen to be using a mail client that doesn't modify the content of the patch and configure it to use Gmail's SMTP server, then it certainly renders that point moot. On the other hand, if it was the SMTP server then it would not be possible to send patches in that fashion regardless of what MUA was used (and would be a bigger problem in terms of contributing to projects that require inline patch submission via email).

>> One thing that I think would be an improvement to git format-patch and git send-email is having it default to setting the Message-Id header in the email it generates rather than relying on the SMTP server to generate it.

> That doesn't make sense, it doesn't know what message id to set.

It could use the value like <commit-sha1>@localdomain. Basically the message-id value should be a relatively unique value.

> It needs to hook in to a mail client to know that.

I think we may not be on the same page here. I was referring to the Message-Id header of the message itself (when it's written to disk by git format-patch), not the value of the In-Reply-To header or the last value in the References header.

So if git format-patch set that header when generating the message (rather than relying on the SMTP server to set that header), then you could easily have it refer to the file generated by the previous invocation by name, via a command option, to retrieve the message-id value and use it to populate the In-Reply-To and References headers (instead of having to retrieve the message from some remote server and copying its message-id value to specify as a command line option).

> but as it stands most if not all web interfaces for MLs are terrible.

This is why I prefer having an NNTP gateway (like gmane) to browse mailing lists using my locally installed MUA (or newsreader).


> If I happen to be using a mail client that doesn't modify the content of the patch and configure it to use Gmail's SMTP server, then it certainly renders that point moot.

The whole point was that I was discussing an alternative to mail clients, however. If this was an issue with clients I would have brought it up with clients.

> It could use the value like <commit-sha1>@localdomain. Basically the message-id value should be a relatively unique value.

git commit --amend breaks this. You need to come up with some stable scheme here. Branch name could work. Ties you to a specific contribution model, though. So does github; but in a more overt way, this could lead to hidden bugs occurring. I usually don't use a branch when contributing to GDB (which uses an ML), for example, I just use a detached head.

> I think we may not be on the same page here. I was referring to the Message-Id header of the message itself (when it's written to disk by git format-patch), not the value of the In-Reply-To header or the last value in the References header.

Yeah, but that's tricky to autoset in a stable way, too, like I say above.

> This is why I prefer having an NNTP gateway (like gmane) to browse mailing lists using my locally installed MUA (or newsreader).

Right, but this just increases the barrier to easy participation


> The whole point was that I was discussing an alternative to mail clients, however. If this was an issue with clients I would have brought it up with clients.

Granted, but I think that if projects require submitting patches via email, then using a local mail client makes it much easier to do so. 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.

>> It could use the value like <commit-sha1>@localdomain. Basically the message-id value should be a relatively unique value.

> git commit --amend breaks this.

No, it doesn't. git am doesn't make any use of the message-id header when applying the patch to your working copy. The commit in your local repository will have a different sha1 compared to the corresponding commit the patch author has (or any other reviewer who has applied that patch to their own working copy for that matter).

Basically the steps would be:

1. Generate a patch series using git format-patch

2. Use git-send-email to send the patches to the mailing list.

3. Get reviews

4. Address comments

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.

The command line parameter that I mention would be able to retrieve the value of the message-id that was generated by the first invocation of git format-patch and then set the values of the In-Reply-To and References headers in the new cover letter message without you having to manually copy it from your original message when viewing it in your MUA (or web browser).

> Yeah, but that's tricky to autoset in a stable way, too, like I say above.

The sha1 of the commit should be unique enough. Assuming the SMTP server doesn't override what was set by the client, then it should work without any issues. I have tested this with one commercial SMTP server by manually setting the Message-Id header in a telnet session and did see it unaltered in the message I received. I still need to run this test with other SMTP servers to see if I get the same result.

>> This is why I prefer having an NNTP gateway (like gmane) to browse mailing lists using my locally installed MUA (or newsreader).

> Right, but this just increases the barrier to easy participation

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 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.


> 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.


> 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.


> 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.


> Not necessarily. There are extensions to set up, proxies to set up if you're behind a firewall, etc.

Default, basic workflow is the same though. For email, this doesn't map well, since everyone has a different workflow; there's not really a "default". And most if not all web-based contribution workflows don't force you to switch browsers (sometimes you may have a couple improvement features on other browsers, but that's not prohibitive), so this discussion is moot anyway.

Proxies are much easier to set up for browsers as I mentioned earlier.

> When you delete a message, it's marked with the expunge flag, IIRC and will be deleted when you end the IMAP session.

Right, but I also don't want to store all my emails locally, just the recent ones, and it's unclear how to do that without getting them deleted. Thunderbird in particular gets very confusing about this (the OSX Mail app is clearer). The first time I set up Thunderbird it synced everything. I didn't want that (I realized that it was going to download my gigabytes of email after it started syncing); but was too afraid to delete the older messages. I eventually went with deleting the profile dir and starting over. This is not just me, multiple people I know have been through similar confusions when setting up.

And, again, none of this is obvious.

"I've never had that problem" misses the point; the point is not that it works a certain way, it's that it's confusing and nonobvious and very easily can turn people off contributing that way.

> 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.

This is how I learn as well. I too am self-taught. But there are many people who do not have the time to learn things by blundering along. Reducing friction wherever possible is something I care about deeply. Not everyone does, but I do try to convince others to strive for the same.

> Ports for secure transports (SMTP, IMAP, etc.) aren't typically blocked by residential ISPs.

Yes, but people live in universities, or other large shared NAT networks, which often blanket port block. I'm not saying that these policies are reasonable, I'm just pointing out the reality of the situation.

And SMTP is what you need to use git send-email, which is what the original discussion was about.


> Default, basic workflow is the same though. For email, this doesn't map well, since everyone has a different workflow; there's not really a "default".

While that is true, I don't see it as an issue. Project documentation can suggest a workflow, but people who regularly contribute can optimize/change it for their convenience. What really matters is what works for the project maintainers and core contributors.

For example, at my current job, we have an established workflow for implementing changes in our code base, reviewing those changes and deploying them to our production systems. If I were to switch jobs, I would have to adapt to the workflow at my new job. I wouldn't try to shoehorn in the workflow used at my current job into my new job. But I would try to suggest improvements to the workflow based on my experience and see if I can get others to adopt them. But if they don't change, then I either have to deal wit it, or find another job. Similarly, if a potential contributor isn't willing to deal with the established workflow of a given project, they're free to contribute to a project that has a workflow more to their liking.

> Right, but I also don't want to store all my emails locally, just the recent ones, and it's unclear how to do that without getting them deleted.

I don't really see it as a problem. I have an email account that was provisioned roughly 8 years ago and the total folder size is around 1.2 GB (which is pretty insignificant in terms of disk space these days). I don't typically delete emails and can easily find messages sent to me from that long ago if I so wish using the search features of my MUA.

But getting to your other point about not wanting to sync the entire set of emails, it's not something that I have to deal with more often than I end up setting up a new computer (which has been twice in the last 5 years or so).

> it's confusing and nonobvious and very easily can turn people off contributing that way.

There are certain expectations that each project has in terms of contributing and I have seen a lot of complaints over the years where people post code, but never follow up with the maintainer. Perhaps having an email based process forces those who are willing to be more involved in the process, and discourages those who just want to drop code off and be done with it (without ever following up).

> But there are many people who do not have the time to learn things by blundering along.

I wouldn't call it "blundering". It's a learning experience. If someone isn't willing to to put the time into independently learning (with assistance as needed) something, then perhaps it's not really worth their time (or yours). I'm much more willing to work with people who, after showing them the basics, come back to me and actually show me something that I didn't know about as opposed to the person who appears to be burdened by the fact that I'm teaching them the basics and has no time to go further in their learning process. The same applies to project maintainers.

> Yes, but people live in universities, or other large shared NAT networks, which often blanket port block.

The only time I've encountered this problem is at my current job where they block access to external email services when connected to the corporate network. I don't bother logging into my personal email accounts at work though. People, if they're motivated enough can get around those restrictions. Perhaps, if there's a blanket port block, they could submit things by connecting to their email server via their cell phone/mobile connection.


> Project documentation can suggest a workflow, but people who regularly contribute can optimize/change it for their convenience. What really matters is what works for the project maintainers and core contributors.

Workflow for interacting with a project is different from workflow for interacting with email, a central tool to the rest of our lives. Git workflow is malleable. If I have to change my email workflow to contribute to your project, I probably just won't contribute, or contribute less. I'm a committer to gdb, but this is one of the reasons I dread putting up patches and often procrastinate. I have an unsynced MUA locally which I do use, but I still don't like it.

Like I said, you can make it so that you only use the mail client for patch contributions, but that feels heavyweight. I've tried that (indeed, it's what I currently do), and it's really annoying.

> I don't really see it as a problem. I have an email account that was provisioned roughly 8 years ago and the total folder size is around 1.2 GB

That's just you, though. Mine is 7GB. On my current laptop that doesn't matter. I used to be on an older laptop that didn't have much space, was partitioned and dual booted, and regularly ran out of space. 7GB was a lot.

> it's not something that I have to deal with more often than I end up setting up a new computer

But we are talking about setup. We are talking about the setup time for contributing to a project for people who don't already use MUAs.

> Perhaps having an email based process forces those who are willing to be more involved in the process, and discourages those who just want to drop code off and be done with it (without ever following up).

I think this attitude does more harm than good. I've been involved with projects with more explicit mentoring, and this has always been a net positive -- for every contributor who drive-by drops a patch, we have many more new contributors who start off clueless but end up being valuable members of the community.

> I wouldn't call it "blundering". It's a learning experience. If someone isn't willing to to put the time into independently learning (with assistance as needed) something

Not everyone can afford to sink unlimited time into things. Making it easier to use things helps these people get involved.

Besides, folks don't always approach open source project with the singular goal of contributing to that particular project. Sometimes they just want to do some open source stuff in the field of their choice to learn. If your project is annoying to get involved in, they will choose a different one -- they're still motivated, just not for your project in particular. Your project doesn't exist in a vacuum.

This is a fundamental disagreement of opinion we seem to have here -- you don't particularly care about such contributors, I do, and I think that such projects (which try hard to keep it easy to contribute) I've been involved in have benefitted tremendously from this. To each to their own, I guess.


> This is a fundamental disagreement of opinion we seem to have here -- you don't particularly care about such contributors, I do

Fair enough. We're obviously not going to change our viewpoints based on this subthread.

It has been an interesting discussion though.


Yep!


Some people hate web as much as you hate email.

Email is ancient, web is bloated.


To be clear, I don't hate e-mail, and you could probably construct a UI for a mailing list that's nice.

On the other hand, doing so would basically just be re-implementing github/gitlab/gitea with a much less optimal storage backend.


Web is far more usable

The big difference here is that you seem to hate web for what amounts to meaningless ideology, whereas people like me hate email for very practical reasons.


I hate web because it provides a user interface instead of a programming interface.

If I don't like the existing user interface to a standardized machine-readable protocol/format, I can write my own user interface for my own needs, as can anyone else, which has two big advantages: People with different needs can have user interfaces that match their respective needs, even while working on the same project, and that leads to easier innovation (when people share their respective solutions).

Now, github currently provides the low-barrier solution that seems to be good enough for many people, which is why the development of tools for email-based workflows is stagnating, instead building more lock-in for github, and preventing any serious improvement in workflows.

So, your hate for email is for practical reasons, but those practical reasons are not inherent properties of email, but rather the result of github trying to capture the market for later exploitation, and you are happy to help them for the momentary convenience, while probably not realizing how much potential convenience you are missing out on as a side effect.


> I hate web because it provides a user interface instead of a programming interface.

https://api.github.com/


Which is mostly missing the point.

First of all, github is not the web, and much of the web does not have an API (and I don't have a clue how good the github API is).

But more importantly, even if they have an API: Is there any legally binding committment on their part that that API will be a reliable basis for me to build on for the next 20 years or so, assuming they still exist then? Won't they change it as it suits their needs, in particular their business needs?

A "programming interface" that I can't rely on in the long run is still kindof a user interface, as I have to bother with it whenever it changes. It's a real programming interface only if I can build an abstraction on top of it and essentially forget the layers beneath.


This is how you submit a patch to an email list: 1. Clone the repository locally 2. Make the fix 3. Run $VCS email --to=<list> 4. Done!

This is how you submit a patch via github: 1. Clone the repository locally 2. Make the fix 3. Fork the repository on GitHub 4. Push your changes to your GitHub fork 5. Go through several screens to make a pull request on GitHub.

(This is assuming you have a GitHub account. If you don't have one, or if you don't know its UI well, insert several more steps in the middle.)

For a casual contributor, sending a patch via email is quite easier than doing it in the web. There are of course downsides to both approaches, but please don't pretend that there are no reasonable objections to web UIs.


Exactly how does it know how to send email from the command line? I'm using gmail. Am I supposed to figure out how to configure gmail for SMTP, put the server and creds in a config file somewhere, and hope I don't bump up against any ISP firewalls or Google security tricks?

Or see Manishearth's comment above.

Meanwhile, you may have to create a Github account and fork the repo for PRs, but I don't see any way for that to not be trivial. Yeah, you gotta know Git, but at least Github has nice easy buttons to guide you through doing things.


> Meanwhile, you may have to create a Github account and fork the repo for PRs, but I don't see any way for that to not be trivial

It's been said. You do it with a service built upon the traditional currency of open source: patches. GitHub-style pull requests are not an intrinsic requirement even for the kind of shiny web UI that GitHub wanted to build. It was, however, an important part of GitHub's lock-out strategy.

If you build your startup so that the way that person B has to get their changes to person A is through a pull request, then you can make sure that not only is person A active in the market for Git hosting, but person B is, too. They'll need to throw their changes up on some Git hosting service, because it has to live somewhere. And if your startup happens to be a Git hosting service, that's good for you. And, hey! since it's a pull request, you can do more than strongly suggest that person B hosts their stuff with you, you can force it, by making it impossible for the pull request to come from off-site.

You can't do that kind of underhanded "growth hacking" if you allow contributors to submit patches, because while pull requests are indirect, patches are self-contained. They are a unit of change.

(I've referred to this in the past as using a strategy of dark patterns inspired by social networks.)

I want to emphasize: "patches vs pull requests" is one matter, and "email vs web UI" is an entirely different matter. It's a 2×2 matrix, not a dichotomy. But this conversation has (annoyingly) run on as if it is "patches (which must be done through email) vs pull requests (which are done through point and click)". There's nothing that precludes GitHub from having built a web UI where today's "pull request" button ended with a "submit patch" button in its place. Nothing.

> I don't see any way for that to not be trivial

Yes, this is clear every time the conversation comes up. Something has happened wrt GitHub that causes people to a) forget how things looked before GitHub, b) have extreme difficulty imagining that things could work any other way—even when the other way is more straightforward and less convoluted than the way GitHub actually works. It's kind of nuts.


It does leave a bad taste in my mouth that github is required, and they could easily do something about it. If they were open about it i probably wouldnt care, but this seems deceptive.


Have we really reached the point where developers don't understand how to setup email? If so, then you're probably right and developing via email is going to be harder for them.


> Am I supposed to figure out how to configure gmail for SMTP,

Not to be condescending, but you can get the necessary information for doing that by using your favorite search engine.

> put the server and creds in a config file somewhere, and hope I don't bump up against any ISP firewalls or Google security tricks?

You could test that by trying to telnet to the SMTP server on the ports they claim to accept connections on. ISPs may block port 25, but they usually don't block ports for secure SMTP connections (like 465 or 587).

As for security tricks, you can always try sending an email to yourself or another email account for testing.


Knowledge is about how to do things. I think we both have enough to figure out how to get a task like that done.

Wisdom is knowing how to choose the simplest possible way to get a job done, i.e. knowing what not to do. I have enough to know which solution I'd rather spend my time on. Do you?


I think it really comes down to the conventions of the project that you wish to contribute to. Anyone is welcome to suggest improvements to the established workflow, but it really isn't productive to rant about something that really should be a non issue.


Just to point out, for drive by commits (eg typo fixes, etc), GitHub is super simple:

  1. Go to the file in GitHub you want to change
  2. Click the "Edit" icon
  3. Click the "Create Pull Request" button
There's no need to create a fork and branch manually any more, GitHub does it automatically behind the scenes. It's a useful optimisation. :)


Though I really wish that GH would cleanup the fork on your profile when the PR is closed, or offer an easy button to nuke those... Minor niggle.


Yep, that would be useful. :)


A casual contributor is more likely to already have a GitHub account than to have git-send-email configured correctly.


Most maintainers aren't looking for "casual contributors." It's a huge pain in the ass to have someone open a half-baked PR and then never respond to feedback or support questions.


Depends on the patch... if it's a typo fix on a readme, or updated url in a documentation file... you click the edit button on github, save, then create PR button after... easy peasy.

It really depends on what you are trying to do in terms of what the process is.. generally, if you aren't a contrib, you will fork, and work from a branch on your locally cloned fork.. you push to that branch, and then create a PR upstream. You may create a local ref to the upstream branch in order to facilitate updates to your fork, and for handling squash/rebase scenarios.

A lot of this is simply git... the "fork" on github creates a github hosted remote copy of the upstream project. The PR is a chance to review upstream patching. Yes, this can be done via email... but you can also do a lot of things in email, that email is a bad user experience for.


This is how you submit a patch to Gerrit: 1. Clone the repository locally 2. Make the fix 3. Run 'git push origin HEAD:refs/for/master'. Done (without needing to setup SMTP.)


Better yet, install `git-review`, a project that came out of OpenStack's use of Gerrit.

1. Clone the repository locally 2. Make the fix 3. Run 'git review'. Done (without needing to remember that annoying refs/for/foo syntax.)


Compare like with like, don't count screens one way and count preconfigured command lines the other way. If you have $VCS set up nicely, it's a one-liner there. If you have GitHub set up nicely, it's a one-liner in GitHub too. If you don't have $VCS set up, it's a large number of obscure manpages. If you don't have GitHub set up, it's a couple of clicks in a friendly UI (and actually far fewer clicks than you list, these days).


Thats actually a good point


I don't hate any and use both every day.


> First, you generally have to join a mailing list, which is regularly broken, or requires someone somewhere to manually acknowledge your membership.

You can usually just send your patch to mailing list without joining at all and you will be replied off the list.

> Then, you have to figure out how they want shit formatted, figure out how to generate a diff (I've been using SVN for 8+ years, git for ~3 years, and have never had to deal with diff files!)

Unbelievable. The only explanation I can find is that you avoided dealing with diffs and used SVN only on your workplace.

> Plus, just reading mailing lists is a fucking disaster. Literally no mailing list host I know of lets you just view a complete topic thread in simple chronological order on ONE PAGE.

Mailing lists are supposed to be read in your email client. If you want an archive, use NNTP archive like gmane.


> You can usually just send your patch to mailing list without joining at all and you will be replied off the list.

News to me. The few times I've gone through the hoops, the ML's have said things like "you have to join to send mail". I think there's at least one ML I'm still waiting on the join confirmation mail.

> Unbelievable. The only explanation I can find is that you avoided dealing with diffs and used SVN only on your workplace.

No, you see there are other ways of interacting with shit like that. With tortoisesvn and tortoisegit, I maybe have to use the command-line git once or twice a month, and that's generally for unfucking coworkers merge-attempts. There are also other ways of dealing with merges, like actual tools for that (winmerge, meld, etc...). I don't see any reason to actually deal with the underlying diffs basically ever.

> Mailing lists are supposed to be read in your email client. If you want an archive, use NNTP archive like gmane.

I was specifically complaining about NNTP archives. I've yet to see a mailing list archive that's readable in a sane manner. And the point is, if I'm a new contributor, I'm not already subscribed to the mailing list, and therefore have no way to reading it in my client, which still doesn't provide a nice "forum-thread" like view which is the best way (in my opinion) of consuming that sort of discussion.


In my experience, in communities that use mailing lists for patch submission as opposed to just discussion, it's the norm to keep posting open to non-subscribers. In the Linux kernel we use so many separate mailing lists that to subscribe to all of them when you just want to send a couple of patches would be a complete disaster. Protocol is to keep posting open to everyone and to ensure that you always use Reply To All to keep every list and individual in the loop on replies.

I don't disagree with you though that mailing lists are painful - and I particularly agree that the archive experience is sorely, sorely, sorely lacking.


Why would anyone have to deal with diff files during regular usage?


Let's say I found a bug in some software I use, and tweaked a few lines to fix it. Now what do I do?

(1) Mail a diff to the author.

(2) Get an account on some random website, "fork" the code, make the tweak again, and "submit a pull request."

I'll choose (1) every time, and will probably just shrug and move on if I'm forced to do (2). I've made a few throwaway GitHub accounts when I cared enough, but I usually don't bother.


I don't like the centralization around a proprietary software, but saying GitHub is a random site isn't fair. A lot of F/OSS people use it. Out of curiosity what happens when you want to submit say a picture to a repo?


I'm not a graphic designer, so I don't usually do that, but I'd probably email the author or development list. Projects with lots of binary files checked into version control are very different from source code, though, so I don't know how they normally operate.


That's what version control is about. Patches upon patches, since SCCS.


Diffs are an internal part of how VC works. There is literally no reason you would ever have to deal with them in their raw format.


> Mailing lists are supposed to be read in your email client. If you want an archive, use NNTP archive like gmane.

Of course, GMANE went down, and when it came back old GMANE URLs are now broken.

I do read all my email in gnus, though, precisely because newsgroup-style mailing lists are so awesome. It's another one of those things: I'm amazed by the lengths people go to in order to justify using inferior solutions like web browsers and web mail when emacs & decades-old software is so much better.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: