6 ms·

The article describes a lot about the workflow, but only two sentences about the advantages: > A very large body of email-related software exists and is equall

The article describes a lot about the workflow, but only two sentences about the advantages: > A very large body of email-related software exists and is equally reliable and well-understood. You can interact with email using only open source software and customize your workflow at every level of the stack - filtering, organizing, forwarding, replying, and so on; in any manner you choose. Using email software in general is well-understood, but using it for Git is much harder than using GitHub. Customizing the workflow is also something you probably shouldn't want to do unless you're really working with a massive project such as the Linux kernel.

hyperpape 8y ago
Agreed. To begin with, telling everyone in your group to just stop using gmail/webmail is a non-starter, so you're going to end up having to lead people through setting up a second set of tools. And whatever the advantages of this workflow are, there are also disadvantages, or at least unanswered questions. How do you switch from inline diffs to side-by-side, toggle whitespace, integrate the results of a linter/static analyzer, etc? It's a good idea to build your collaboration tools on top of plain text/simple interfaces, but there are also a lot of needs that push you in the direction of a complex/powerful app. I was interested in the idea of alternative git tooling, but I don't think this article really delivers.
- Sir_Cmpwn 8y ago
  I think these concerns are valid, and also addressed in the article towards the end. I believe the correct answer is not to throw these tools away like GitHub et al chooses to do, but to build upon them instead. Getting everyone to jump ship from webmail is hard, but instead of taking these tools away from email power-users I want to make web tools for e.g. interacting with mailing lists more powerful via my work on sr.ht.
  - hyperpape 8y ago
    > and also addressed in the article towards the end. Your perception might be that they're addressed, because you see your vision of how things should work. But to me, I can't see more than "trust me, I'm working on it". The value of that assurance depends on how well you see the limitations of the older workflows, not just their advantages. If you build it, that will assuage most worries, but talking about what you need in addition to the pure email workflow, and showing how it can be built would also help your case.
    - Sir_Cmpwn 8y ago
      Well, I admit some minor digging is necessary to see what I have planned. The marketing page for sr.ht gives you an idea: https://sr.ht https://sr.ht There's more tangible stuff here than "trust me, I'm working on it", I hope. A lot of the non-mail-related work exists and I'm getting started on mail stuff now, so I'm starting to write about it to spurn discussion and start paying attention to people's concerns with the approach. You can also see some of the specific email-related stuff I have going if you want to dig some more: https://git.sr.ht/~sircmpwn/lists.sr.ht/ https://git.sr.ht/~sircmpwn/lists.sr.ht/ https://git.sr.ht/~emersion/python-emailthreads/ https://git.sr.ht/~emersion/python-emailthreads/ The latter in particular could give some good insight into how this stuff is going to take shape. Would love to hear more of your concerns, keep them coming!
begriffs 8y ago
> The article describes a lot about the workflow, but only two sentences about the advantages The article is a good complement to one that I wrote about specifically the advantages - https://begriffs.com/posts/2018-06-05-mailing-list-vs-github.html https://begriffs.com/posts/2018-06-05-mailing-list-vs-github...
- Boulth 8y ago
  I've read your article. I was excellent! One thing I missed though was an real life, actual example of discussing a bug and then submitting a patch, including all git commands.
shmerl 8y ago
I think the only real benefit is good scalability for really massive projects. Otherwise, using something like Github and the like is clearly much easier.
Sir_Cmpwn 8y ago
Author here. I didn't load all of the advantages into a single conveniently-quotable part of the article, but I think I covered them all the same. In addition to what you quoted: >reviewing patches is quite easy with the email approach as well [...] It’s just email - you can reply, forward the message, Cc interested parties, start several chains of discussion, and so on The quote you gave also misses an important point directly preceeding it, which is that email is decentralized and federated. I also wouldn't understate the importance of all of it being open source.
- cryptonector 8y ago
  That's all true, but (and note: I didn't downvote you) the problem I have with email for code review is that finding all the comments made over time on one patch is... a chore. Mind you, for many years I did code review over email, so I'm used to it, and since I'm a TUI sort of person, it works very very well for me except for the chore that is finding and collating all comments. This chore is very real, and very time consuming. Reviewers need to make sure that new versions of a patch are responsive to past [accepted] commentary. Authors need to find all commentary when updating patches in order to be responsive to it. Not that code review tools from GitHub, GitLab, and others, are all that good. I've yet to find a code review tool that really works for me and the people I work with. Whether you use email as a transport and/or interface, or something more weby, or whatever, at the end of the day, for me, the real win lies in code review and commentary management and UIs. Because I'm a TUI person, my approach would be to build a code/patch+commentary format, something like (designing on the fly here): - foo.c | /* This is code (or patch) */ ? jane ^^^^^^^^^^^^ ? jon The above is code, yes, but this is commentary! | while (!review_done) | ...; or - 0001-This-is-a.patch | diff ... ... Something more markdown-y would work too. An XML version wouldn't be a bad idea, provided a) that the schema is trivial, b) that there are tools for converting between a simple text format (e.g., like the above), c) preferably things round-trip. Obviously, with XSLT/XPath, (b) should be feasible, especially if we heed (a). And (c) should be possible if the XML schema is kept simple enough (but see below). What's nice about this is that as long as there is version information we can merge commentary from many emails into one document (per file/patch), which then could make automation of commentary collation possible. This needs lots more thought, I grant that. For example: how to cut-down quoted text without losing the ability to trivially merge commentary? Also, it would be very tempting to add lots of metadata, which would drive one to XML. I'm not a huge fan of XML, mostly due to lack of TUI editors for it... but XML does have the advantage of XSLT/XPath. It seems to me that this is a problem that can be solved reasonably well, and that this is a problem worth solving. If we can solve it in a way that works well with TUIs, it will also work well with email, so this should be of interest to you (I hope so as you seem to have the time and energy to work on this!). Thoughts?

hyperpape 8y ago

Agreed. To begin with, telling everyone in your group to just stop using gmail/webmail is a non-starter, so you're going to end up having to lead people through setting up a second set of tools. And whatever the advantages of this workflow are, there are also disadvantages, or at least unanswered questions. How do you switch from inline diffs to side-by-side, toggle whitespace, integrate the results of a linter/static analyzer, etc? It's a good idea to build your collaboration tools on top of plain text/simple interfaces, but there are also a lot of needs that push you in the direction of a complex/powerful app. I was interested in the idea of alternative git tooling, but I don't think this article really delivers.

Sir_Cmpwn 8y ago
I think these concerns are valid, and also addressed in the article towards the end. I believe the correct answer is not to throw these tools away like GitHub et al chooses to do, but to build upon them instead. Getting everyone to jump ship from webmail is hard, but instead of taking these tools away from email power-users I want to make web tools for e.g. interacting with mailing lists more powerful via my work on sr.ht.
- hyperpape 8y ago
  > and also addressed in the article towards the end. Your perception might be that they're addressed, because you see your vision of how things should work. But to me, I can't see more than "trust me, I'm working on it". The value of that assurance depends on how well you see the limitations of the older workflows, not just their advantages. If you build it, that will assuage most worries, but talking about what you need in addition to the pure email workflow, and showing how it can be built would also help your case.
  - Sir_Cmpwn 8y ago
    Well, I admit some minor digging is necessary to see what I have planned. The marketing page for sr.ht gives you an idea: https://sr.ht https://sr.ht There's more tangible stuff here than "trust me, I'm working on it", I hope. A lot of the non-mail-related work exists and I'm getting started on mail stuff now, so I'm starting to write about it to spurn discussion and start paying attention to people's concerns with the approach. You can also see some of the specific email-related stuff I have going if you want to dig some more: https://git.sr.ht/~sircmpwn/lists.sr.ht/ https://git.sr.ht/~sircmpwn/lists.sr.ht/ https://git.sr.ht/~emersion/python-emailthreads/ https://git.sr.ht/~emersion/python-emailthreads/ The latter in particular could give some good insight into how this stuff is going to take shape. Would love to hear more of your concerns, keep them coming!

begriffs 8y ago

> The article describes a lot about the workflow, but only two sentences about the advantages The article is a good complement to one that I wrote about specifically the advantages - https://begriffs.com/posts/2018-06-05-mailing-list-vs-github.html https://begriffs.com/posts/2018-06-05-mailing-list-vs-github...

Boulth 8y ago
I've read your article. I was excellent! One thing I missed though was an real life, actual example of discussing a bug and then submitting a patch, including all git commands.

shmerl 8y ago

I think the only real benefit is good scalability for really massive projects. Otherwise, using something like Github and the like is clearly much easier.

Sir_Cmpwn 8y ago

Author here. I didn't load all of the advantages into a single conveniently-quotable part of the article, but I think I covered them all the same. In addition to what you quoted: >reviewing patches is quite easy with the email approach as well [...] It’s just email - you can reply, forward the message, Cc interested parties, start several chains of discussion, and so on The quote you gave also misses an important point directly preceeding it, which is that email is decentralized and federated. I also wouldn't understate the importance of all of it being open source.

cryptonector 8y ago
That's all true, but (and note: I didn't downvote you) the problem I have with email for code review is that finding all the comments made over time on one patch is... a chore. Mind you, for many years I did code review over email, so I'm used to it, and since I'm a TUI sort of person, it works very very well for me except for the chore that is finding and collating all comments. This chore is very real, and very time consuming. Reviewers need to make sure that new versions of a patch are responsive to past [accepted] commentary. Authors need to find all commentary when updating patches in order to be responsive to it. Not that code review tools from GitHub, GitLab, and others, are all that good. I've yet to find a code review tool that really works for me and the people I work with. Whether you use email as a transport and/or interface, or something more weby, or whatever, at the end of the day, for me, the real win lies in code review and commentary management and UIs. Because I'm a TUI person, my approach would be to build a code/patch+commentary format, something like (designing on the fly here): - foo.c | /* This is code (or patch) */ ? jane ^^^^^^^^^^^^ ? jon The above is code, yes, but this is commentary! | while (!review_done) | ...; or - 0001-This-is-a.patch | diff ... ... Something more markdown-y would work too. An XML version wouldn't be a bad idea, provided a) that the schema is trivial, b) that there are tools for converting between a simple text format (e.g., like the above), c) preferably things round-trip. Obviously, with XSLT/XPath, (b) should be feasible, especially if we heed (a). And (c) should be possible if the XML schema is kept simple enough (but see below). What's nice about this is that as long as there is version information we can merge commentary from many emails into one document (per file/patch), which then could make automation of commentary collation possible. This needs lots more thought, I grant that. For example: how to cut-down quoted text without losing the ability to trivially merge commentary? Also, it would be very tempting to add lots of metadata, which would drive one to XML. I'm not a huge fan of XML, mostly due to lack of TUI editors for it... but XML does have the advantage of XSLT/XPath. It seems to me that this is a problem that can be solved reasonably well, and that this is a problem worth solving. If we can solve it in a way that works well with TUIs, it will also work well with email, so this should be of interest to you (I hope so as you seem to have the time and energy to work on this!). Thoughts?