Hacker News new | comments | show | ask | jobs | submit login
Mailing lists vs Github (begriffs.com)
82 points by samber 4 months ago | hide | past | web | favorite | 44 comments



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.


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://public-inbox.org/git/

https://www.mercurial-scm.org/pipermail/mercurial-devel/2018...

https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00210.html

http://lists.llvm.org/pipermail/llvm-commits/

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.


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]


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?


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


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

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)

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.


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


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.


On both points, every problem has its own set of best solutions. If your problem is running a big community around a big project where running listserv+debbugs (or the like) is just minutiae, that's the best way to go. If you're medium-to-big, there are umbrella projects that can adopt your project and supply you these tool (e.g. GNU and Apache do this), but your project would need to be useful to some bigger audience and comply with the umbrella project. Otherwise you can just put a the source code up your server as tarballs or VCS repos maybe using one of the readymade web interfaces (viewvc, cgit, gitweb, hgweb, etc.) and hosting your discussions on sth. like librelist.com or google groups; or just use sth. like GitHub or Gitlab without much worry.

Principles are best when they are abstract and a few. Then we apply them to concrete situations. If that makes the best answer to perpetually be "it depends", be it so, for its better than cargo cult answers.

Also, the discussion does not seem to be around Github alternatives, as the arguments against it in the article could equally be made against Gitlab (a private instance or the public one), Bitbucket or similar. The article is comparing two models, and is not about a post-Github world.


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


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.


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


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.


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


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.


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.


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.


I was thinking of writing this blog post too. Maybe I still will, because I want to emphasise something different about this topic.

Mailing list workflows also make people write a different sort of commit, where the diffs are short and readable and the commit messages are persuasive as to why the diff should be accepted. That's because these diffs and commit messages are going to be much more prominent in people's mailboxes, so both should be as readable as possible. Extraneous things such as style fixes or whitespace changes within the same diff are frowned upon because they bring clutter and hinder readability (it's okay to throw those into a separate commit and thus a separate email, though).

I find this style of commits immensely useful when reading the project's history, but their value is hard to convey to someone raised on Github, which strongly discourages this style of commits. Most Github users I've seen never read the project's history, because they value neither writing it nor reading it.


I think that one of the reasons is that the mailing list workflow tends to produce a final deliverable (commit) that makes sense by itself because the whole context will be hard to find (no direct link to mailing list discussion). On GitHub instead when you find a commit you’re always one click away from the PR that produced it, with its discussion inside.


> I’d advise creating a general purpose listserv for your personal use

I think this is the elephant in the room. If there were a way of setting up a listserv that were as easy as creating a GitHub project then mailing lists would have a chance of taking off.


A friend and former cow-orker of mine (who is also a big open source advocate) has ran FreeLists [0] for, I dunno, 15 years or more. I don't know that it gets much easier than that.

> FreeLists provides the internet community with Free, no-hassle, high-quality mailing lists. We don't use advertisements and we don't charge for higher-than-a-certain-volume lists.

[0]: https://www.freelists.org/about.html


A mailing list reader/aggregator would be a good start, i.e. something to bring all mailing lists into one place and make them searchable/readable as threads. I know there are options on Linux, but I'm talking about a web-based one with 2018 standards, that even JS devs can use.


And that is/was Gmane. But it's dying a slow death due to disinterest. You can access it via the NNTP protocol.


There is! https://www.topicbox.com/

It's for pay though. It also provides a JMAP interface, so you can programatically access messages (as well as having permalinks with the message and thread IDs in them)

It's not 100% designed for this usecase, but it's definitely got the nicest archive view format of any mailing list manager I've ever used.

(disclaimer: I haven't worked directly on it, but I am a part owner of the company which wrote it)


For reference, here is an example of a large open source project that uses Topicbox for its mailing lists: https://illumos.topicbox.com/


One thing mailing lists can do to be better is:

* allow non-subscribers to post.

* do not enable Reply-To: header generation which excludes non-subscribers from receiving replies. See https://www.unicom.com/pw/reply-to-harmful.html

If you want people to submit a patch or bug report via mailing list, but you make people subscribe before they can post, that is a major barrier.

In the olden days, mailing lists worked without stringent subscription requirements. Subscription is a tool for those who want to get all future traffic. Now it is used for spam control.

I've run into people who are vehemently in favor of Reply-To munging. The reasons are always idiotic and can be summarized as follows, "you must join this mailing list and read everything that goes on for a while before posting, or else fuck you! We don't need clueless postings from casual outsiders who can't be bothered to subscribe and drink all the Kool-Aid."

* It's 2018! For pete's sake, allow HTML. HTML mails allow a modicum of formatting. The occasional image is useful too. Most people have HTML capable mail readers. There is such a thing as being too conservative.

I allow HTML in all my mailing lists, and allow HTML to propagate into the mail archives. (After careful security scrubbing.)

I wrote this flex-scanner-driven HTML cleaner in C for the purpose: http://www.kylheku.com/cgit/hc/tree/ It uses a whitelist of HTML tags and for each whitelisted tag, a whitelist of attributes. All else is stripped away.


> Another nice effect is that other people can carry the patch to the finish line if the original author stops caring or being involved.

There are ways of picking up a patch from an MIA author on github. Users can tick "allow maintainers to contribute" which allows maintainers of the root project access to push to their forks particular branch. If that fails, you can just get the diff from github and continue the work without losing the code. Git (and github) support multiple authors so you can still give credit where credit is due, however it isn't baked into the github permissions and UI. Obviously this case in particular is presented easier than on GitHub, but you still have the same options available to you.


Has a project ever stored their mailing list archive in their git repo as text files? It would be nice if I could pull down the latest issues and grep them instead of relying on a remote database with crippled search functionality.

I like Git GUIs, but I would rather run them locally and use flat files instead of databases. I use git-cola for visualizing the git DAG locally, it would be nice to do the same for issue and patch threads.

Edit: https://github.com/dspinellis/git-issue looks interesting



https://public-inbox.org/hosted.html

To be frank, I don't think this it's practical, except for small projects. I tried to clone git's mailing list archive, but I ran out of memory. :-/


If you just pull the current version and not the full history it isn't that bad (769.04 MiB).

    $ git clone https://public-inbox.org/git/ --depth=1
    Cloning into 'git'...
    remote: Enumerating objects: 349282, done.
    remote: Counting objects: 100% (349282/349282), done.
    remote: Compressing objects: 100% (324048/324048), done.
    remote: Total 349282 (delta 25234), reused 348128 (delta 25234)
    Receiving objects: 100% (349282/349282), 769.04 MiB | 8.26 MiB/s, done.
    Resolving deltas: 100% (25234/25234), done.
    Checking out files: 100% (349024/349024), done.


You can always use an ftp client or rsync to fetch mailing lists as a bunch of mboxes, and use a program like notmuch or mairix to search them very fast (not sure if notmuch supports mbox though, but I've used mairix in the past and it's nice).


The idea that open source was better when mailing lists were the norm is somewhat absurd.

Back in the days when everything ran on lists, I did not contribute once. With Github, I started making two or three small improvements per week and took own responsibility for a few projects.

Maybe larger projects worked more smoothly, with people being more involved in development. But that experience could easily be recreated on Github. Just make it as difficult as possible to contribute, and you'll always end up with a small circle of dedicated contributors.


> When you browse a Github project you know exactly how it works. Sure, the addons/CI/hooks may differ, and setting up the project might involve some contortions, but the process of browsing code, finding known bugs, and submitting changes is always the same.

Bullshit.

Browsing the code associated with a mailing-list-driven project is standard. If the code is in Git, then it's some Cgit or Gitweb. You just need to know the URL. Chances are very good that all the URLs you need are on the project home page.

Submitting a patch is exactly the same for any mailing list. Use "git format-patch" locally, then send the relevant parts of the output.

Bug tracking may differ depending on what that project is running, but there are major systems for that. Unless the project developed something from scratch, it will be one of those.

By contrast, code browsing, submission and tracking all differ for different code hosting sites. The point that these workflows are the same if everyone just goes with one company is moronic. When is anything not the same between customers of the same company? Do we really want FOSS developers to all depend on one company for their workflow? That's like admitting FOSS is useless; it can't even host itself.


"Where Gitlab has a CI server built in, and several addons exist for Github, I don’t know of any clearly dominant thing for a patch based workflow. "

QEMU uses patchew which collect email patches, then deploys to OpenShift servers for continuous integration testing.

https://github.com/patchew-project/patchew


And then there's Patchwork which can be easily integrated with Jenkins.


> It can look silly to write an email while offline, only to have it queue, send, and arrive after another better response renders yours unnecessary. It’s probably wise to include a signature line saying something like, “Note: composed offline, may lack recent context.”

Surely the Date: and References: headers already convey that context.


Plus that can happen just as easily on a web UI like GitHub.


> the threaded nature of emails

This is not consistent with my experience with emails, especially compared to github.


Threaded presentation of a mailbox something you may have to turn on in your mail client, which has to have threading support.

Many non-programmers have enough computer savvy to do this.


Hmm.. I think many programmers do not have enough email savvy to know this exists.


Well at least we know what the author favors.


This is a very long (4.5k words long) and in depth article.

Maybe you could write it with a shorter TL;DR focused on the main differences between mailing lists vs. github.

With more in depth discussions like diff formats and mailing list software at a later point in time. Right now it just reads as a massive blob of text intertwined with detailed tutorials in between.

Anyway, IMHO they're two different use cases with two different audiences. I quite enjoyed the sometimes not so nice discussions on patches on the mplayer ml. But I also like the fairly simple fork, merge request github workflow(but maybe that's because i'm no longer an active maintainer anywhere).

I think there should be more mailing lists for some things. It seems to me as if people tend to see a lot of things as an either or. Either you use mailing lists for everything or you put all your annoying conversations in github issues. Why?


> On Github, comments continually change. They become “outdated” and disappear when attached to a line that has been changed

You can view them if you go to the commit on which the comment was made.

>Furthermore, patches from multiple authors can’t mix in a Github pull request. The person opening the pull request “owns” it.

Actually, no. Pull requests are for reveiwing one branch. If that branch is accessible to multiple authors they can be collaborate on that branch

> annotating the hunk headers with which C functions are affected

Seems like you can do this with git as well : https://stackoverflow.com/a/16528858/3528640

> and the choice of various algorithms such as “patience.”

Again, possible with git

> Finally, there’s nothing to stop the mailing list style of collaboration from adapting to emerging diff formats, such as structural diffs

I don't think Git/Github developers will sit idle when improved collaboration methods are discovered

> The bulk of communication around a new feature is in its proposal, not around the subsequent code

This can be done by opening issues or by simply using a Google doc. Mailing lists are not a very good solution to this. There is a lot of extraneous garbage that needs to be parsed before getting to the meaty stuff

etc etc.

Most of author's complaints seems to not be entirely accurate

> Challenges for mailing lists

One big challenge is also how good Github is, the UX is well done. Almost every time I wanted to do something there is button right there to do it. Also, it is very fast. Projects like PJAX[1] has meant that Github is miles ahead of competition. I have used Github, Gerrit etc and I have to say, once you started using Github, there is no going back

[1] https://github.com/defunkt/jquery-pjax When a Github user clicks on a link, it is converted to an XHR request and then only the part of the page that needs to change are fetched. The page is updated and browser history is manipulated using PushState to not break the back button !




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

Search: