5 ms·

This is a beautifully detailed but self-refuting argument. The self-refutation comes midway through, when the author admits: "To be honest I can’t say that I’ve

This is a beautifully detailed but self-refuting argument. The self-refutation comes midway through, when the author admits: "To be honest I can’t say that I’ve contributed to non-Github projects either." OK — so maybe the possible advantages of the mailing list workflow are just not working out behaviorally? There's something so frustrating about the underlying desire to roll back the history of technology, as if that could cure the problems of the present. I mean, I too used to enjoy reading email in a terminal. It felt fun twenty years ago. Over a modem connection. But I really don't think we can go back to it, and even less should we romanticize it as if that was "the true old days." In fact, the problems of the past are precisely what got us to the present. This piece left me feeling that what we need are new proposals for the future, rather than nostalgia for a past that wasn't all that.

jordigh 8y ago
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.
megous 8y ago
Just because author doesn't use mailing lists, doesn't mean it's a self-refuting argument, or that nobody else does. Also it's a comparison with pros/cons. What's to refute? It's quite acurate, and I liked the depth. One other major dis-benefit of github is hiding of contact information. If you're communicating on ML, you autmatically have everyone's email, and can contact them privately or publicly any time, even when ML goes away. What happens when github goes away? Or you're banned. Or it's banned in a certain country. Even if it's for a day or two. You have to build contacts outside of github in order not to lose them, and bother people even if you don't intend to communicate atm.
- kazinator 8y ago
  Author doesn't say he or she doesn't use mailing list; only that he or she hasn't submitted a code change through a mailing list, for undisclosed reasons.
bachmeier 8y ago
> I mean, I too used to enjoy reading email in a terminal. It felt fun twenty years ago. Over a modem connection. But I really don't think we can go back to it This doesn't really help your argument, because that's not how people use, say, gmail in 2018. > the problems of the past are precisely what got us to the present If you're comparing mailing lists and Github, I don't think that's true at all. Github started with Git, then they said "let's tack this other stuff on top of Git to improve the workflow". It's not like Github was what happened when mailing lists evolved. Maybe you can combine the best of both technologies.
- decasia 8y ago
  Just a quick note on the email point — the specific thing I was responding to was this from TFA: "Many people, especially younger devs, have never seen a real mail client like mutt. In their minds they may picture an overflowing GMail inbox full of top posted replies all mixed together from different projects. That’s not an enticing image. Perhaps this article can start these developers on the path to rediscovering the care and engineering that went into classic email clients." My point is that this is nostalgia for terminal-based email clients.
  - gkya 8y ago
    Need not be. The important thing with mutt is that it's standards compliant, it helps follow the conventions of these communities, and as a plus it's easily configurable and scriptable. If there are GUI tools that bear the same properties, they are equally viable (AFAIK Claws comes close).
gkya 8y ago
> This is a beautifully detailed but self-refuting argument. The self-refutation comes midway through, when the author admits: "To be honest I can’t say that I’ve contributed to non-Github projects either." So because I'm not homosexual and not a female, I cannot support gender equality or denounce homophobia? The school of thought that new replaces old no exceptions is boringly wrong. Github flow has its advantages. I as a solo amateur hacker cannot devote the time to maintain my mailing-list+bug-tracker or my gitlab instance, thus putting things on the platform with a wide userbase is a better option. For my private stuff I keep them offline anyways. But I've sent patches both to Emacs via the mailing list and to various OSS projects on github, and the latter was more confusing to me. Still, they were equally useful in that I could get the task done multiple times using them. Just like pen&paper vs. digital. I'm deep into Org mode, notes agenda ox-latex and everything, but many things are just better with pen&paper, and the digital equivalents won't catch up soon (no energy needed, typing on touchscreens suck, touchscreens suck in general, especially when you need to do things quickly, pen and paper are cheap and widely available). Or just like microwave did not kill the traditional oven or replace the stove.
- decasia 8y ago
  On your substantive point, I have no quarrel whatsoever with mixing old and new tech. I think we all do that, in practice. But what we're talking about is not just whether we mix old and new tech but where we go from here given that GitHub-based development has its problems. If there are good examples of new OSS projects that use mailing list based workflows, I'd love to hear them. The usual examples (see elsewhere in this thread) are, like Linux, usually pretty dated. My view is that the mailing list-based workflow seems to have some real problems and just advocating a return to it is... probably a bit short-sighted. As far as your comments about what makes an argument self-refuting, my point is that it is potentially contradictory to say that X is considerably better than Y even while you can't actually be bothered to do X. If X is "gender equality" then the analogy would be "We should all practice gender equality but as a man I personally want my wife to stay home and keep house." That's self-contradictory in a specific way that "I'm a man and I advocate gender equality" just isn't.
  - 8y ago
funzis 8y ago
> I mean, I too used to enjoy reading email in a terminal. It felt fun twenty years ago. Over a modem connection. But I really don't think we can go back to it, and even less should we romanticize it as if that was "the true old days." Why? I've used mutt as my primary email client for 12 years now. I get that most people aren't interested by that, nor am I trying to tell you you should do it, but I'd at least like to point out that it's fully possible, and I have no problem dealing with HTML mail. I have yet to see a killer feature that would move me away from mutt---or an incompatibility of mutt that causes enough of a problem to switch.
im3w1l 8y ago
We shouldn't we dream about the anachronistic past that never existed, with the best of the old and none of it's problems? That it never existed doesn't mean it we can't use it to inspire the future.
wowaname 8y ago
GitHub promotes a walled-garden approach to development. People who use it will want you to have an account on it, and some people such as myself cannot or will not use GitHub at any cost. I have my own cgit instance I host my own code on, and I contribute to anyone else's projects through mailing lists or other open forms of contact. It doesn't require a sign-up; it requires something that everyone on the Internet already has: an E-mail address. Git is a decentralised protocol that goes hand-in-hand very well with the federated nature of E-mail. GitHub destroys that, and just because it has a shiny web interface and has encouraged "social coding", people forget how Git really is and refuse to take an old-fashioned PR patchset because they want it done through the GitHub interface, or they refuse a bug ticket because it isn't in the issues list that requires you to log in. (My concern with bug trackers requiring registration extends past GitHub; I would rather every tracker simply require a valid E-mail address to send in a new ticket.) All of this simply helps to fragment the OSS community and its collaboration even more than it already is. So yeah, some people prefer E-mail for the utility rather than for the "hackerman aesthetic" as you assume it to be. It's nothing about nostalgia; I'm a pretty young developer who hasn't had a chance to grow up in the dialup days and I still see the benefits of using mail as a primary form of development communication. Don't fix what isn't broken.

jordigh 8y ago

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.

megous 8y ago

Just because author doesn't use mailing lists, doesn't mean it's a self-refuting argument, or that nobody else does. Also it's a comparison with pros/cons. What's to refute? It's quite acurate, and I liked the depth. One other major dis-benefit of github is hiding of contact information. If you're communicating on ML, you autmatically have everyone's email, and can contact them privately or publicly any time, even when ML goes away. What happens when github goes away? Or you're banned. Or it's banned in a certain country. Even if it's for a day or two. You have to build contacts outside of github in order not to lose them, and bother people even if you don't intend to communicate atm.

kazinator 8y ago
Author doesn't say he or she doesn't use mailing list; only that he or she hasn't submitted a code change through a mailing list, for undisclosed reasons.

bachmeier 8y ago

> I mean, I too used to enjoy reading email in a terminal. It felt fun twenty years ago. Over a modem connection. But I really don't think we can go back to it This doesn't really help your argument, because that's not how people use, say, gmail in 2018. > the problems of the past are precisely what got us to the present If you're comparing mailing lists and Github, I don't think that's true at all. Github started with Git, then they said "let's tack this other stuff on top of Git to improve the workflow". It's not like Github was what happened when mailing lists evolved. Maybe you can combine the best of both technologies.

decasia 8y ago
Just a quick note on the email point — the specific thing I was responding to was this from TFA: "Many people, especially younger devs, have never seen a real mail client like mutt. In their minds they may picture an overflowing GMail inbox full of top posted replies all mixed together from different projects. That’s not an enticing image. Perhaps this article can start these developers on the path to rediscovering the care and engineering that went into classic email clients." My point is that this is nostalgia for terminal-based email clients.
- gkya 8y ago
  Need not be. The important thing with mutt is that it's standards compliant, it helps follow the conventions of these communities, and as a plus it's easily configurable and scriptable. If there are GUI tools that bear the same properties, they are equally viable (AFAIK Claws comes close).

gkya 8y ago

> This is a beautifully detailed but self-refuting argument. The self-refutation comes midway through, when the author admits: "To be honest I can’t say that I’ve contributed to non-Github projects either." So because I'm not homosexual and not a female, I cannot support gender equality or denounce homophobia? The school of thought that new replaces old no exceptions is boringly wrong. Github flow has its advantages. I as a solo amateur hacker cannot devote the time to maintain my mailing-list+bug-tracker or my gitlab instance, thus putting things on the platform with a wide userbase is a better option. For my private stuff I keep them offline anyways. But I've sent patches both to Emacs via the mailing list and to various OSS projects on github, and the latter was more confusing to me. Still, they were equally useful in that I could get the task done multiple times using them. Just like pen&paper vs. digital. I'm deep into Org mode, notes agenda ox-latex and everything, but many things are just better with pen&paper, and the digital equivalents won't catch up soon (no energy needed, typing on touchscreens suck, touchscreens suck in general, especially when you need to do things quickly, pen and paper are cheap and widely available). Or just like microwave did not kill the traditional oven or replace the stove.

decasia 8y ago
On your substantive point, I have no quarrel whatsoever with mixing old and new tech. I think we all do that, in practice. But what we're talking about is not just whether we mix old and new tech but where we go from here given that GitHub-based development has its problems. If there are good examples of new OSS projects that use mailing list based workflows, I'd love to hear them. The usual examples (see elsewhere in this thread) are, like Linux, usually pretty dated. My view is that the mailing list-based workflow seems to have some real problems and just advocating a return to it is... probably a bit short-sighted. As far as your comments about what makes an argument self-refuting, my point is that it is potentially contradictory to say that X is considerably better than Y even while you can't actually be bothered to do X. If X is "gender equality" then the analogy would be "We should all practice gender equality but as a man I personally want my wife to stay home and keep house." That's self-contradictory in a specific way that "I'm a man and I advocate gender equality" just isn't.
- 8y ago

funzis 8y ago

> I mean, I too used to enjoy reading email in a terminal. It felt fun twenty years ago. Over a modem connection. But I really don't think we can go back to it, and even less should we romanticize it as if that was "the true old days." Why? I've used mutt as my primary email client for 12 years now. I get that most people aren't interested by that, nor am I trying to tell you you should do it, but I'd at least like to point out that it's fully possible, and I have no problem dealing with HTML mail. I have yet to see a killer feature that would move me away from mutt---or an incompatibility of mutt that causes enough of a problem to switch.

im3w1l 8y ago

We shouldn't we dream about the anachronistic past that never existed, with the best of the old and none of it's problems? That it never existed doesn't mean it we can't use it to inspire the future.

wowaname 8y ago

GitHub promotes a walled-garden approach to development. People who use it will want you to have an account on it, and some people such as myself cannot or will not use GitHub at any cost. I have my own cgit instance I host my own code on, and I contribute to anyone else's projects through mailing lists or other open forms of contact. It doesn't require a sign-up; it requires something that everyone on the Internet already has: an E-mail address. Git is a decentralised protocol that goes hand-in-hand very well with the federated nature of E-mail. GitHub destroys that, and just because it has a shiny web interface and has encouraged "social coding", people forget how Git really is and refuse to take an old-fashioned PR patchset because they want it done through the GitHub interface, or they refuse a bug ticket because it isn't in the issues list that requires you to log in. (My concern with bug trackers requiring registration extends past GitHub; I would rather every tracker simply require a valid E-mail address to send in a new ticket.) All of this simply helps to fragment the OSS community and its collaboration even more than it already is. So yeah, some people prefer E-mail for the utility rather than for the "hackerman aesthetic" as you assume it to be. It's nothing about nostalgia; I'm a pretty young developer who hasn't had a chance to grow up in the dialup days and I still see the benefits of using mail as a primary form of development communication. Don't fix what isn't broken.