5 ms·

Mailing lists vs Github

82 points by samber 8y ago

msft_employee 8y ago
We can all relax - Microsoft isn't going to kill GitHub
baud147258 8y ago
Well at least we know what the author favors.
rjzzleep 8y ago
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?
jordigh 8y ago
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 8y ago
  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 8y ago
> 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 8y ago
  Plus that can happen just as easily on a web UI like GitHub.
decasia 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." 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.
  - 8y ago
tome 8y ago
> 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 8y ago
  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 8y ago
    And that is/was Gmane. But it's dying a slow death due to disinterest. You can access it via the NNTP protocol.
- brongondwana 8y ago
  There is! https://www.topicbox.com/ 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)
  - chrismorgan 8y ago
    For reference, here is an example of a large open source project that uses Topicbox for its mailing lists: https://illumos.topicbox.com/ https://illumos.topicbox.com/
- jlgaddis 8y ago
  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 https://www.freelists.org/about.html
matt4077 8y ago
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.
deckar01 8y ago
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
- gkya 8y ago
  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).
- jwilk 8y ago
  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 8y ago
    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.
- dredmorbius 8y ago
  There's mh: https://en.wikipedia.org/wiki/MH_Message_Handling_System https://en.wikipedia.org/wiki/MH_Message_Handling_System https://www.cs.indiana.edu/docproject/mail/mh.html https://www.cs.indiana.edu/docproject/mail/mh.html
pmd 8y ago
"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 8y ago
  And then there's Patchwork which can be easily integrated with Jenkins.
bluehatbrit 8y ago
> 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.
kazinator 8y ago
> 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.
recursive 8y ago
> the threaded nature of emails This is not consistent with my experience with emails, especially compared to github.
- kazinator 8y ago
  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 8y ago
    Hmm.. I think many programmers do not have enough email savvy to know this exists.
kazinator 8y ago
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.
simula67 8y ago
> 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 !

82 points by samber 8y ago

msft_employee 8y ago

We can all relax - Microsoft isn't going to kill GitHub

baud147258 8y ago

Well at least we know what the author favors.

rjzzleep 8y ago

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?

jordigh 8y ago

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 8y ago
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 8y ago

> 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 8y ago
Plus that can happen just as easily on a web UI like GitHub.

decasia 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." 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.
- 8y ago

tome 8y ago

> 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 8y ago
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 8y ago
  And that is/was Gmane. But it's dying a slow death due to disinterest. You can access it via the NNTP protocol.
brongondwana 8y ago
There is! https://www.topicbox.com/ 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)
- chrismorgan 8y ago
  For reference, here is an example of a large open source project that uses Topicbox for its mailing lists: https://illumos.topicbox.com/ https://illumos.topicbox.com/
jlgaddis 8y ago
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 https://www.freelists.org/about.html

matt4077 8y ago

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.

deckar01 8y ago

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

gkya 8y ago
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).
jwilk 8y ago
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 8y ago
  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.
dredmorbius 8y ago
There's mh: https://en.wikipedia.org/wiki/MH_Message_Handling_System https://en.wikipedia.org/wiki/MH_Message_Handling_System https://www.cs.indiana.edu/docproject/mail/mh.html https://www.cs.indiana.edu/docproject/mail/mh.html

pmd 8y ago

"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 8y ago
And then there's Patchwork which can be easily integrated with Jenkins.

bluehatbrit 8y ago

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

kazinator 8y ago

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

recursive 8y ago

> the threaded nature of emails This is not consistent with my experience with emails, especially compared to github.

kazinator 8y ago
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 8y ago
  Hmm.. I think many programmers do not have enough email savvy to know this exists.

kazinator 8y ago

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.

simula67 8y ago

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