Re: [PATCH v4] send-email: Add simple email aliases format

> Allen Hubbe <allenbh@gmail.com> writes:
>
>> On Fri, May 22, 2015 at 10:44 AM, Junio C Hamano <gitster@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.
>