Re: [PATCH v4] send-email: Add simple email aliases format
On Fri, May 22, 2015 at 12:29 AM, Eric Sunshine sunsh...@sunshineco.com wrote: On Thu, May 21, 2015 at 11:40 PM, Allen Hubbe alle...@gmail.com wrote: This format is more simple than the other alias file formats, so it may be preferred by some users. [...] Signed-off-by: Allen Hubbe alle...@gmail.com --- diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt index 804554609def..38ade31e0c28 100644 --- a/Documentation/git-send-email.txt +++ b/Documentation/git-send-email.txt @@ -383,7 +383,29 @@ sendemail.aliasesFile:: sendemail.aliasFileType:: Format of the file(s) specified in sendemail.aliasesFile. Must be - one of 'mutt', 'mailrc', 'pine', 'elm', or 'gnus'. + one of 'simple', 'mutt', 'mailrc', 'pine', 'elm', or 'gnus'. ++ +If the format is 'simple', then the alias file format is described below. +Descriptions of the other file formats to the following formats can be found in +the documentation of the email program of the same name. The second sentence probably needs some proof-reading. Could you be more specific? ++ +This 'simple' format is is as follows. ++ + alias: address|alias[, address|alias...] ++ +Aliases are specified one per line. There is no line splitting. Anything on a +line after and including a `#` symbol is considered a comment, and is ignored. +Blank lines are ignored. I'm not convinced that gratuitously diverging from the sendmail/postfix 'aliases' format is warranted. In particular, that This isn't 'sendmail', as of v2. format recognizes a comment line only when '#' is the first non-whitespace character[1]; and does not consider '#' a comment-introducer anywhere else in the line. By recognizing '#' anywhere as a comment-introducer, you may be painting this format into a corner rather than leaving it open for someone later to extend it to be more sendmail/postfix-like by, for instance, supporting name quoting and line-continuation[1]. It depends what we want to do with this parser: accept existing sendmail aliases files in git, or enforce that git alias files are usable for sendmail. I really don't expect the second to ever happen. The first, maybe, but only if the alias file is edited to remove aliases of pipes and maildirs etc. The second may not work if we have comments to the right, or aliases of aliases, which sendmail does not claim to support. I don't know what sendmail would actually do with a '#' elsewhere. It only talks about having '#' at the beginning of a line, or in the alias name in quotes (which is not supported by this parser - proper handling of quoted strings is not easy). It doesn't say what sendmail does with '#' if the name is not quoted, and it doesn't define a meaning for '#' in the definition of an alias. If these other cases would be errors for sendmail, so what if they are not errors here? For the same reason, I'm not convinced that simple is a good name. I was worried about that back in v1 before going to v2, but I really don't have a strong opinion about the name. I already changed the name, at the suggestion of Junio. I'd like to hear a consensus from you two, or a tiebreaker from a third, before I change it again. sendmail may indeed be a more appropriate name, even if it means that this early implementation documents it as (currently) a subset of the richer sendmail/postfix 'aliases' format. By doing so, we leave the door open so a future person can implement additional features to bring it closer to that format. Or, a future person can write a sendmail parser that is closer to that format. [1]: http://www.postfix.org/aliases.5.html ++ +Example of the 'simple' format: ++ + alice: Alice W Land a...@example.com + bob: Robert Bobbyton b...@example.com + # this is a comment + # this is also a comment + chloe: ch...@example.com + abgroup: alice, bob # comment after an alias + bcgrp: bob, chloe, Other o...@example.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] send-email: Add simple email aliases format
Allen Hubbe alle...@gmail.com writes: It depends what we want to do with this parser: accept existing sendmail aliases files in git, or enforce that git alias files are usable for sendmail. I really don't expect the second to ever happen. The first, maybe, but only if the alias file is edited to remove aliases of pipes and maildirs etc. The second may not work if we have comments to the right, or aliases of aliases, which sendmail does not claim to support. Let me step back a bit. Earlier you said your aim is not to use an alias file you already have and use with the MUA/MTA, but to have a collection of aliases to use with git-send-email only. Is there a reason to add support for a new format (whether it is compatible to or subset of postfix/sendmail format, or a totally new one) for that goal? What makes the existing formats unsuitable? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] send-email: Add simple email aliases format
On Fri, May 22, 2015 at 10:44 AM, Junio C Hamano gits...@pobox.com wrote: Allen Hubbe alle...@gmail.com writes: It depends what we want to do with this parser: accept existing sendmail aliases files in git, or enforce that git alias files are usable for sendmail. I really don't expect the second to ever happen. The first, maybe, but only if the alias file is edited to remove aliases of pipes and maildirs etc. The second may not work if we have comments to the right, or aliases of aliases, which sendmail does not claim to support. Let me step back a bit. Earlier you said your aim is not to use an alias file you already have and use with the MUA/MTA, but to have a collection of aliases to use with git-send-email only. Is there a reason to add support for a new format (whether it is compatible to or subset of postfix/sendmail format, or a totally new one) for that goal? What makes the existing formats unsuitable? It's just a matter of personal preference what is suitable or not, for me, in my environment, etc. Is there a reason I should use the alias format of some email client, if I don't use that email client? I'm not trying to force anything on anyone else by offering this, just another option that might be suitable for someone else, in their environment, as it is in mine. People who don't like it can choose a different option. People who don't like any of the options can write their own like I did, or is that not allowed for some reason? I've already shown that I am willing to change the name, write the documentation, write the tests, modify the syntax, and so on. I've done the work, from +6 lines to +57 lines, as requested. I'm not looking forward to v5, v6... v10 of what was a really really simple patch. If you don't like it, please don't string me along. This is not my job. If you think the patch is generally ok, but could be improved to be accepted, then let's together try to make v5 the last. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] send-email: Add simple email aliases format
On Fri, May 22, 2015 at 8:12 AM, Allen Hubbe alle...@gmail.com wrote: On Fri, May 22, 2015 at 12:29 AM, Eric Sunshine sunsh...@sunshineco.com wrote: On Thu, May 21, 2015 at 11:40 PM, Allen Hubbe alle...@gmail.com wrote: +If the format is 'simple', then the alias file format is described below. +Descriptions of the other file formats to the following formats can be found in +the documentation of the email program of the same name. The second sentence probably needs some proof-reading. Could you be more specific? Unable to parse of the other file formats to the following formats. I'm guessing that the to the following formats portion doesn't belong. It depends what we want to do with this parser: accept existing sendmail aliases files in git, or enforce that git alias files are usable for sendmail. Aside from these possibilities (likely or unlikely), there is also the issue of breaking expectations. Precedence for this style 'aliases' format was set decades ago by sendmail. People are familiar with it and understand its strengths and weaknesses. Even if documented as not being sendmail-compatible, because it's so similar to sendmail 'aliases', people will expect it to work the same way, thus unless there's a good reason to diverge from that standard format, it makes sense to be compatible with it (even if only as a proper subset). I really don't expect the second to ever happen. The first, maybe, but only if the alias file is edited to remove aliases of pipes and maildirs etc. The second may not work if we have comments to the right, or aliases of aliases, which sendmail does not claim to support. It's not clear why you say that sendmail does not claim to support aliases of aliases. Although it's true that some sources, such as [1], fail to mention support explicitly, other more authoritative sources do[2]. Moreover, the 1993 sendmail book by Bryan Costales, with contributions from Eric Allman (the creator of sendmail), talks explicitly about expansion of aliases on the right-hand-side. Finally, since time immemorial (at least the early 1980's), every /etc/aliases file has contained the following mandatory entries: postmaster: root MAILER-DAEMON: postmaster which indicates clearly that alias expansion on the RHS is supported. [1]: http://www.feep.net/sendmail/tutorial/intro/aliases.html [2]: https://www.freebsd.org/cgi/man.cgi?query=aliasessektion=5 I don't know what sendmail would actually do with a '#' elsewhere. It only talks about having '#' at the beginning of a line, or in the alias name in quotes (which is not supported by this parser - proper handling of quoted strings is not easy). It doesn't say what sendmail does with '#' if the name is not quoted, and it doesn't define a meaning for '#' in the definition of an alias. If these other cases would be errors for sendmail, so what if they are not errors here? All the more reason to stick with the documented standard. When you diverge from it, you paint the format into a corner, thus closing the door on someone who wants to bring it more in line with the standard. For the same reason, I'm not convinced that simple is a good name. sendmail may indeed be a more appropriate name, even if it means that this early implementation documents it as (currently) a subset of the richer sendmail/postfix 'aliases' format. By doing so, we leave the door open so a future person can implement additional features to bring it closer to that format. Or, a future person can write a sendmail parser that is closer to that format. Yes, but git maintainers must continue to support your simple format even if someone comes along later and adds a more proper sendmail-like format alongside. That's why these questions and observations are being raised now: not to string you along and not because your proposal is necessarily undesirable, but because once such support lands in git, then it remains indefinitely and must be supported for the life of the project. Long-term project health is important, which is why it's desirable to consider these issues early, and to avoid painting ourselves into a corner. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] send-email: Add simple email aliases format
On Fri, May 22, 2015 at 2:01 PM, Allen Hubbe alle...@gmail.com wrote: On Fri, May 22, 2015 at 12:53 PM, Eric Sunshine sunsh...@sunshineco.com wrote: On Fri, May 22, 2015 at 8:12 AM, Allen Hubbe alle...@gmail.com wrote: For the same reason, I'm not convinced that simple is a good name. sendmail may indeed be a more appropriate name, even if it means that this early implementation documents it as (currently) a subset of the richer sendmail/postfix 'aliases' format. By doing so, we leave the door open so a future person can implement additional features to bring it closer to that format. Or, a future person can write a sendmail parser that is closer to that format. Yes, but git maintainers must continue to support your simple format even if someone comes along later and adds a more proper sendmail-like format alongside. Someone might implement a sendmail parser in the future, or perhaps never. So, there is the possibility. How strong of a reason is that to reject some other format that is based on a colon? Nobody has suggested that your format should be rejected. Rather, the issue raised regards gratuitous divergence from the sendmail 'aliases' format. You seem to be arguing in favor of gratuitous divergence (without explanation) despite the proposed proper subset approach serving your use-case just as well. What is the harm of the two side by side? This is only a small bit of code that really shouldn't require much maintenance. What is the harm to just leave it in? If the future sendmail parser happens to support the simple format, and the future maintainers determine the situation to be unacceptable, there is still a solution. Simply define both names 'simple' and 'sendmail' to refer to the same sendmail parser. The dead code can be removed. This simple solution doesn't work if your new format diverges from the sendmail 'aliases' format, which is why the issue is being raised now, in order to avoid painting ourselves into that corner. If, on the other hand, your new format remains a proper subset of sendmail 'aliases', then the simple solution does work; and, as a proper subset, it can just as well be named sendmail without hurting any future effort to implement missing functionality. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] send-email: Add simple email aliases format
Allen Hubbe alle...@gmail.com writes: On Fri, May 22, 2015 at 10:44 AM, Junio C Hamano gits...@pobox.com wrote: Let me step back a bit. Earlier you said your aim is not to use an alias file you already have and use with the MUA/MTA, but to have a collection of aliases to use with git-send-email only. Is there a reason to add support for a new format (whether it is compatible to or subset of postfix/sendmail format, or a totally new one) for that goal? What makes the existing formats unsuitable? It's just a matter of personal preference what is suitable or not, for me, in my environment, etc. Is there a reason I should use the alias format of some email client, if I don't use that email client? I do not think should is a good word in the context of that sentence, as nobody is forcing you to choose one of the existing formats. But one reason you might want to do so would be because git-send-email already knows about it. It is a different matter if you already use an email client that supports your new format and you are trying to reuse an alias file with that email client. But I got an impression that was not the case, so the choice seemed to me between - learning and using one of existing 5; and - inventing, adding support for, and using a new one. That felt to me was a choice that is clearly not in favor of the latter, and I was wondering if there were other reasons to shift the balance. For example, all of the existing formats are klunky and difficult to write might be why learning and using one of existing 5 is not a win, compared to inventing, ading support for, and using a new one. I do not know if that is the case, so I wanted to hear the reason why. I'm not trying to force anything on anyone else by offering this, just another option that might be suitable for someone else, in their environment, as it is in mine. People who don't like it can choose a different option. People who don't like any of the options can write their own like I did, or is that not allowed for some reason? We prefer not to carry dead code---when we add things, we would want to make sure it will be widely useful so that other people benefit. I've already shown that I am willing to change the name, write the documentation, write the tests, modify the syntax, and so on. I've done the work, from +6 lines to +57 lines, as requested. I'm not looking forward to v5, v6... v10 of what was a really really simple patch. If you don't like it, please don't string me along. This is not my job. Yeah, I know. A trade off from contributor's side is between (1) handing the maintenance to the upstream, so that a feature will stay available with minimum fuss in the future, or (2) having to carry one's own enhancement forward every time one updates from the upstream. On the other hand, a trade off from project's side is between (1) rejecting a half-way finished ware and hurting feelings of people and (2) accepting a half-way finished ware and having to spend engineering effort (e.g. making sure it fits to the rest of the system without adding dead weight) to polish it to the end. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] send-email: Add simple email aliases format
On Fri, May 22, 2015 at 12:53 PM, Eric Sunshine sunsh...@sunshineco.com wrote: On Fri, May 22, 2015 at 8:12 AM, Allen Hubbe alle...@gmail.com wrote: On Fri, May 22, 2015 at 12:29 AM, Eric Sunshine sunsh...@sunshineco.com wrote: On Thu, May 21, 2015 at 11:40 PM, Allen Hubbe alle...@gmail.com wrote: +If the format is 'simple', then the alias file format is described below. +Descriptions of the other file formats to the following formats can be found in +the documentation of the email program of the same name. The second sentence probably needs some proof-reading. Could you be more specific? Unable to parse of the other file formats to the following formats. I'm guessing that the to the following formats portion doesn't belong. Thanks. It's obvious now that it's pointed out. It's hard to proofread one's own writing. It depends what we want to do with this parser: accept existing sendmail aliases files in git, or enforce that git alias files are usable for sendmail. Aside from these possibilities (likely or unlikely), there is also the issue of breaking expectations. Precedence for this style 'aliases' format was set decades ago by sendmail. People are familiar with it and understand its strengths and weaknesses. Even if documented as not being sendmail-compatible, because it's so similar to sendmail 'aliases', people will expect it to work the same way, thus unless there's a good reason to diverge from that standard format, it makes sense to be compatible with it (even if only as a proper subset). I really don't expect the second to ever happen. The first, maybe, but only if the alias file is edited to remove aliases of pipes and maildirs etc. The second may not work if we have comments to the right, or aliases of aliases, which sendmail does not claim to support. It's not clear why you say that sendmail does not claim to support aliases of aliases. Although it's true that some sources, such as [1], fail to mention support explicitly, That's why I said it. other more authoritative sources do[2]. Moreover, the 1993 sendmail book by Bryan Costales, with contributions from Eric Allman (the creator of sendmail), talks explicitly about expansion of aliases on the right-hand-side. Finally, since time immemorial (at least the early 1980's), every /etc/aliases file has contained the following mandatory entries: postmaster: root MAILER-DAEMON: postmaster which indicates clearly that alias expansion on the RHS is supported. Ok, no harm then if aliases are supported. [1]: http://www.feep.net/sendmail/tutorial/intro/aliases.html [2]: https://www.freebsd.org/cgi/man.cgi?query=aliasessektion=5 I don't know what sendmail would actually do with a '#' elsewhere. It only talks about having '#' at the beginning of a line, or in the alias name in quotes (which is not supported by this parser - proper handling of quoted strings is not easy). It doesn't say what sendmail does with '#' if the name is not quoted, and it doesn't define a meaning for '#' in the definition of an alias. If these other cases would be errors for sendmail, so what if they are not errors here? All the more reason to stick with the documented standard. When you diverge from it, you paint the format into a corner, thus closing the door on someone who wants to bring it more in line with the standard. Giving this a different name leaves the door open to someone who wants to write a sendmail parser. Naming it sendmail and diverging from the standard would close that door. For the same reason, I'm not convinced that simple is a good name. sendmail may indeed be a more appropriate name, even if it means that this early implementation documents it as (currently) a subset of the richer sendmail/postfix 'aliases' format. By doing so, we leave the door open so a future person can implement additional features to bring it closer to that format. Or, a future person can write a sendmail parser that is closer to that format. Yes, but git maintainers must continue to support your simple format even if someone comes along later and adds a more proper sendmail-like format alongside. Someone might implement a sendmail parser in the future, or perhaps never. So, there is the possibility. How strong of a reason is that to reject some other format that is based on a colon? What is the harm of the two side by side? This is only a small bit of code that really shouldn't require much maintenance. What is the harm to just leave it in? If the future sendmail parser happens to support the simple format, and the future maintainers determine the situation to be unacceptable, there is still a solution. Simply define both names 'simple' and 'sendmail' to refer to the same sendmail parser. The dead code can be removed. That's why these questions and observations are being raised now: not to string you along and not because your proposal is necessarily undesirable, but
Re: [PATCH v4] send-email: Add simple email aliases format
On Fri, May 22, 2015 at 1:17 PM, Junio C Hamano gits...@pobox.com wrote: Allen Hubbe alle...@gmail.com writes: On Fri, May 22, 2015 at 10:44 AM, Junio C Hamano gits...@pobox.com wrote: Let me step back a bit. Earlier you said your aim is not to use an alias file you already have and use with the MUA/MTA, but to have a collection of aliases to use with git-send-email only. Is there a reason to add support for a new format (whether it is compatible to or subset of postfix/sendmail format, or a totally new one) for that goal? What makes the existing formats unsuitable? It's just a matter of personal preference what is suitable or not, for me, in my environment, etc. Is there a reason I should use the alias format of some email client, if I don't use that email client? I do not think should is a good word in the context of that sentence, as nobody is forcing you to choose one of the existing formats. But one reason you might want to do so would be because git-send-email already knows about it. It is a different matter if you already use an email client that supports your new format and you are trying to reuse an alias file with that email client. But I got an impression that was not the case, so the choice seemed to me between - learning and using one of existing 5; and I imagine that's what most people would do, faced with the same issue. I did initially go look at those formats. Since I didn't really prefer any of them, I approached solving the problem in a different way. - inventing, adding support for, and using a new one. That felt to me was a choice that is clearly not in favor of the latter, and I was wondering if there were other reasons to shift the balance. For example, all of the existing formats are klunky and difficult to write might be why learning and using one of existing 5 is not a win, compared to inventing, ading support for, and using a new one. I do not know if that is the case, so I wanted to hear the reason why. That for example is it. Why should I have to type alias before each alias in the file? It's not in any way hard to do - it just serves no purpose other than to make the parser happy. Perhaps the keyword does serve a purpose in mutt, but for me it is pointless to type that. I'm not trying to force anything on anyone else by offering this, just another option that might be suitable for someone else, in their environment, as it is in mine. People who don't like it can choose a different option. People who don't like any of the options can write their own like I did, or is that not allowed for some reason? We prefer not to carry dead code---when we add things, we would want to make sure it will be widely useful so that other people benefit. 1 vote for useful. I realize this is self serving, but I hoped sharing it would benefit others. I've already shown that I am willing to change the name, write the documentation, write the tests, modify the syntax, and so on. I've done the work, from +6 lines to +57 lines, as requested. I'm not looking forward to v5, v6... v10 of what was a really really simple patch. If you don't like it, please don't string me along. This is not my job. Yeah, I know. A trade off from contributor's side is between (1) handing the maintenance to the upstream, so that a feature will stay available with minimum fuss in the future, or (2) having to carry one's own enhancement forward every time one updates from the upstream. (3) good citizenship in open source to share one's changes to the code. On the other hand, a trade off from project's side is between (1) rejecting a half-way finished ware and hurting feelings of people and (2) accepting a half-way finished ware and having to spend engineering effort (e.g. making sure it fits to the rest of the system without adding dead weight) to polish it to the end. I get that, in the general case, and especially for large features that affect a lot of the user base. How worried are you in this case, about (2), for such a small amount of code that now has a more extensive unit test case and documentation than any of the other options? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] send-email: Add simple email aliases format
On Thu, May 21, 2015 at 11:40 PM, Allen Hubbe alle...@gmail.com wrote: This format is more simple than the other alias file formats, so it may be preferred by some users. [...] Signed-off-by: Allen Hubbe alle...@gmail.com --- diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt index 804554609def..38ade31e0c28 100644 --- a/Documentation/git-send-email.txt +++ b/Documentation/git-send-email.txt @@ -383,7 +383,29 @@ sendemail.aliasesFile:: sendemail.aliasFileType:: Format of the file(s) specified in sendemail.aliasesFile. Must be - one of 'mutt', 'mailrc', 'pine', 'elm', or 'gnus'. + one of 'simple', 'mutt', 'mailrc', 'pine', 'elm', or 'gnus'. ++ +If the format is 'simple', then the alias file format is described below. +Descriptions of the other file formats to the following formats can be found in +the documentation of the email program of the same name. The second sentence probably needs some proof-reading. ++ +This 'simple' format is is as follows. ++ + alias: address|alias[, address|alias...] ++ +Aliases are specified one per line. There is no line splitting. Anything on a +line after and including a `#` symbol is considered a comment, and is ignored. +Blank lines are ignored. I'm not convinced that gratuitously diverging from the sendmail/postfix 'aliases' format is warranted. In particular, that format recognizes a comment line only when '#' is the first non-whitespace character[1]; and does not consider '#' a comment-introducer anywhere else in the line. By recognizing '#' anywhere as a comment-introducer, you may be painting this format into a corner rather than leaving it open for someone later to extend it to be more sendmail/postfix-like by, for instance, supporting name quoting and line-continuation[1]. For the same reason, I'm not convinced that simple is a good name. sendmail may indeed be a more appropriate name, even if it means that this early implementation documents it as (currently) a subset of the richer sendmail/postfix 'aliases' format. By doing so, we leave the door open so a future person can implement additional features to bring it closer to that format. [1]: http://www.postfix.org/aliases.5.html ++ +Example of the 'simple' format: ++ + alice: Alice W Land a...@example.com + bob: Robert Bobbyton b...@example.com + # this is a comment + # this is also a comment + chloe: ch...@example.com + abgroup: alice, bob # comment after an alias + bcgrp: bob, chloe, Other o...@example.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
