
Mailing lists vs Github - samber
https://begriffs.com/posts/2018-06-05-mailing-list-vs-github.html
======
decasia
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
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...](https://www.mercurial-scm.org/pipermail/mercurial-
devel/2018-June/thread.html)

[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
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
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?

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

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

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

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

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

------
kazinator
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](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/](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.

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

------
deckar01
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](https://github.com/dspinellis/git-issue) looks interesting

~~~
jwilk
[https://public-inbox.org/hosted.html](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. :-/

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

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

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

------
pmd
"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](https://github.com/patchew-
project/patchew)

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

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

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

------
recursive
> the threaded nature of emails

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

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

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

------
baud147258
Well at least we know what the author favors.

------
rjzzleep
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?

------
simula67
> 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](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](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 !

