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

[Junio C Hamano <gitster@pobox.com>]

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.