6 ms·

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 t

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?
- emersion 8y ago
  Hi, I'm the author of emailthreads, mentionned in the article. I believe the library is already able to do something pretty close to what you want. See for example this output: https://github.com/emersion/python-emailthreads/blob/master/test/data/multiple-replies/output3.txt https://github.com/emersion/python-emailthreads/blob/master/... (you can find source messages in the parent directory) The goal is to eventually build a web UI around this library.
  - cryptonector 8y ago
    Oh, I skipped that paragraph. Oy, sorry. I think the text format for interleaving source and commentary needs its own discussion somewhere, and probably a standalone repository separate from implementation (and some day preferably too, an RFC, or at least a MIME type registration). I've looked at the examples you linked, and... I like that the review format for review authoring is just plain trivial. Not sure how it works with quote trimming... I'm not sure I like the output format, but I'll go think about it.
    - Sir_Cmpwn 8y ago
      The output format is just a means of testing the library, not the final user-facing form this will take.
    - emersion 8y ago
      >I think the text format for interleaving source and commentary needs its own discussion somewhere, and probably a standalone repository separate from implementation (and some day preferably too, an RFC, or at least a MIME type registration). Yeah, this library just parses email threads and the goal isn't to define a new format. This particular output format is just for debugging and unit testing, it's not meant to e actually used as is. The library user just gets a tree of text fragments with metadata, it's up to him how the output will look like.
  - Alex3917 8y ago
    What's the main difference between the library you're building and mail parser?: https://pypi.org/project/mail-parser/ https://pypi.org/project/mail-parser/ Since there isn't any documentation, I'm just trying to figure out what's it's actually doing (without reading the source).
s73v3r_ 8y ago
But email chains are universally terrible. You also lose the ability to look at the context around the lines in the diff from the review itself.

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?

emersion 8y ago
Hi, I'm the author of emailthreads, mentionned in the article. I believe the library is already able to do something pretty close to what you want. See for example this output: https://github.com/emersion/python-emailthreads/blob/master/test/data/multiple-replies/output3.txt https://github.com/emersion/python-emailthreads/blob/master/... (you can find source messages in the parent directory) The goal is to eventually build a web UI around this library.
- cryptonector 8y ago
  Oh, I skipped that paragraph. Oy, sorry. I think the text format for interleaving source and commentary needs its own discussion somewhere, and probably a standalone repository separate from implementation (and some day preferably too, an RFC, or at least a MIME type registration). I've looked at the examples you linked, and... I like that the review format for review authoring is just plain trivial. Not sure how it works with quote trimming... I'm not sure I like the output format, but I'll go think about it.
  - Sir_Cmpwn 8y ago
    The output format is just a means of testing the library, not the final user-facing form this will take.
  - emersion 8y ago
    >I think the text format for interleaving source and commentary needs its own discussion somewhere, and probably a standalone repository separate from implementation (and some day preferably too, an RFC, or at least a MIME type registration). Yeah, this library just parses email threads and the goal isn't to define a new format. This particular output format is just for debugging and unit testing, it's not meant to e actually used as is. The library user just gets a tree of text fragments with metadata, it's up to him how the output will look like.
- Alex3917 8y ago
  What's the main difference between the library you're building and mail parser?: https://pypi.org/project/mail-parser/ https://pypi.org/project/mail-parser/ Since there isn't any documentation, I'm just trying to figure out what's it's actually doing (without reading the source).

s73v3r_ 8y ago

But email chains are universally terrible. You also lose the ability to look at the context around the lines in the diff from the review itself.