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.
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.
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?
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?
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).
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.
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.
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.
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.
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.
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.
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.
"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.
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.
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 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.
> 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.
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)
* 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.
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.
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
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. :-/
$ 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.
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.
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.
QEMU uses patchew which collect email patches, then deploys to OpenShift servers for continuous integration testing.
Surely the Date: and References: headers already convey that context.
This is not consistent with my experience with emails, especially compared to github.
Many non-programmers have enough computer savvy to do this.
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?
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
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 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
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 !