6 ms·

I have pretty much only contributed to non-Github projects, and let me tell you: mailing list workflows are not a thing of the past. They're still used by big p

I have pretty much only contributed to non-Github projects, and let me tell you: mailing list workflows are not a thing of the past. They're still used by big players like Linux, git, Mercurial, gcc, LLVM, and at least some BSDs: https://lkml.org/ https://lkml.org/ https://public-inbox.org/git/ https://public-inbox.org/git/ https://www.mercurial-scm.org/pipermail/mercurial-devel/2018-June/thread.html https://www.mercurial-scm.org/pipermail/mercurial-devel/2018... https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00210.html https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00210.html http://lists.llvm.org/pipermail/llvm-commits/ http://lists.llvm.org/pipermail/llvm-commits/ https://marc.info/?l=openbsd-tech&r=1&b=201804 https://marc.info/?l=openbsd-tech&r=1&b=201804 Some have integrated other tools into the process like Gerrit or Phabricator, without fundamentally altering the style of the process, i.e. patches first, and discussion on individual patches, not on final hairball diffs. There's a lot of value to this style of development. I consider PRs to be write-only. Few people bother to make PRs readable. I think Github did the same thing for commits that Gmail did for email and top-posting: just hide most of it, so that people don't have to bother with writing it correctly. In the case of github, by default you see the final hairball with the actual commits and their commit messages hidden away in a little tab. This in turn tends to produce a history that's not a very valuable thing to read.

decasia 8y ago
Sure, I wasn't trying to say there are no current projects that use mailing list workflows. My point was just about the specific logic of this article. I think it is self-contradictory to say "It's better to do X but I personally can't be bothered to do X because X is too hard." In the abstract, there is no technical reason why mailing list workflows can't work. But technology is pretty path dependent. The projects you mention are all quite old in technology terms. Would they be using mailing list workflows if they were started today? [edit: wording]
- kazinator 8y ago
  The author never reveals the reason why he or she didn't contribute to a mailing-list driven project. You're only assuming that it's the difficulty of copy and pasting a patch into an e-mail and clicking send; no such thing is written in the blog. People who are motivated to hack on a program will usually find a way to submit. Only programmers who've never been employed balk at using e-mail. If someone won't send me a patch because they are afraid of e-mail, that tells me they've never accepted a meeting request or submitted a status report. What else do they find "too hard"? Testing the code?
Rjevski 8y ago
I just clicked on the LKML website and I have literally no idea what to do next. It’s like a mailbox full of patches without even any clear indication for which source file it is, which patch is the latest, etc. I also don’t even know how to reply/comment on those. On GitHub I can register/login and comment straight away from the web interface. Just because some “die hard” programmers believe antiquated workflows are the best for them doesn’t mean it’s best for everyone else. There’s a reason Github took off (Git was around for years before, but Github made it accessible to a lot more people).
- kazinator 8y ago
  > Git was around for years before, but Github made it accessible to a lot more people. Implementation of Git began in April 2005. 1.0 was released in December. (https://en.wikipedia.org/wiki/Git#History https://en.wikipedia.org/wiki/Git#History) Github had 2000 users in March 1, 2008. [...] Development of the GitHub platform began on October 19, 2007 (https://en.wikipedia.org/wiki/GitHub#Company_history https://en.wikipedia.org/wiki/GitHub#Company_history) So "for years" means "less than three years". Github doesn't make Git accessible. You clone a local Git repo and it behooves you to know how to use it.

decasia 8y ago

Sure, I wasn't trying to say there are no current projects that use mailing list workflows. My point was just about the specific logic of this article. I think it is self-contradictory to say "It's better to do X but I personally can't be bothered to do X because X is too hard." In the abstract, there is no technical reason why mailing list workflows can't work. But technology is pretty path dependent. The projects you mention are all quite old in technology terms. Would they be using mailing list workflows if they were started today? [edit: wording]

kazinator 8y ago
The author never reveals the reason why he or she didn't contribute to a mailing-list driven project. You're only assuming that it's the difficulty of copy and pasting a patch into an e-mail and clicking send; no such thing is written in the blog. People who are motivated to hack on a program will usually find a way to submit. Only programmers who've never been employed balk at using e-mail. If someone won't send me a patch because they are afraid of e-mail, that tells me they've never accepted a meeting request or submitted a status report. What else do they find "too hard"? Testing the code?

Rjevski 8y ago

I just clicked on the LKML website and I have literally no idea what to do next. It’s like a mailbox full of patches without even any clear indication for which source file it is, which patch is the latest, etc. I also don’t even know how to reply/comment on those. On GitHub I can register/login and comment straight away from the web interface. Just because some “die hard” programmers believe antiquated workflows are the best for them doesn’t mean it’s best for everyone else. There’s a reason Github took off (Git was around for years before, but Github made it accessible to a lot more people).

kazinator 8y ago
> Git was around for years before, but Github made it accessible to a lot more people. Implementation of Git began in April 2005. 1.0 was released in December. (https://en.wikipedia.org/wiki/Git#History https://en.wikipedia.org/wiki/Git#History) Github had 2000 users in March 1, 2008. [...] Development of the GitHub platform began on October 19, 2007 (https://en.wikipedia.org/wiki/GitHub#Company_history https://en.wikipedia.org/wiki/GitHub#Company_history) So "for years" means "less than three years". Github doesn't make Git accessible. You clone a local Git repo and it behooves you to know how to use it.