David Kastrup <dak@gnu.org> writes:

> Werner LEMBERG <wl@gnu.org> writes:
>
>>>> No submitter can brow-beat us into accepting a patch because they
>>>> think it is "clear" or "right" or "obvious".  This isn't how
>>>> collaboration works in the free software world.  We decide who has
>>>> commit rights, and we reserve the right to reject and revert
>>>> commits.
>>> 
>>> I provided clarification several times.  It was ignored.
>>
>> Certainly not.  You got *a lot* of replies.
>>
>>> Let me list some different mails in which I repeated more or less
>>> the same explanation with different wording:
>>
>> This is exactly the `agree to disagree' situation I've mentioned in a
>> previous e-mail.
>
> Well, these days generally "discussion" is understood as everybody
> repeating his opinion until most drop out, maybe a trickling down from
> the culture of political debate, with a focus on scoring points rather
> than extending one's views.
>
> This mode of discussion tends to work rather bad in a closed round of
> experts.  Repeating your point on the assumption that your opponent was
> just too dumb to get it the first time gets old rather fast.  Instead of
> making the same point over and over again and riling everybody including
> yourself up in the process, you better try bringing up new facts or
> considerations.  Everything else is only likely to affect the emotional
> but not the factual result of the discussion.
>
> While "everybody's glad that this is over and one will not meet ever
> again" may be a somewhat emotionally conclusive resolution in substitute
> for a convergence to factual agreement, it's not much of a basis for
> ongoing work.

That sounds like saying a discussion where people stick to a clear,
thoroughly and carefully explained point, and don't move on until it's
addressed are silly political discussions, and a discussion between
experts should rather look like one where everyone just jumps in and
brings up another unique perspective which fails to address what was
shortly brought up.

I have to disagree, and offer an alternative analysis by someone who's
not me and is quite a bit better at social issues than me.

    The usual approach on emacs-devel when dealing with something they
    don't like is to come up with random arguments, ignore
    counter-arguments, and move goalposts around because getting
    convinced by arguments is not something you do on the internet.

    From the glimpse I took, that's roughly what's happening there:
    They don't like the idea because gut feeling, so they nitpick
    irrelevancies and go off on tangents to support their gut feeling.

    ...

    [Them] Taylan, could you summarize your core issue here? Not what
    e-d is discussing, but what would you want to happen as the ideal
    outcome?

    [Me] Shell-quote-argument should cleanly document its semantics in
    a way that gives a security-aware programmer confidence that they
    can use the function without worrying about injection.

    [Them] That was the purpose of your [PATCH] thread?

    [Me] That's the summary of the shell-quote-argument bug report.
    The original [PATCH] thread just wants to get shqq into ELPA.

    [Them] Is shqq getting into ELPA?

    [Me] They could have taken it as-is and worked on the "duplication
    of code" (one line of code) later.  They want it neither with the
    one line of duplicated effort, nor do they want to address the
    shell-quote-argument bug report, and I don't want it in ELPA with
    potentially broken semantics.

    [Them] Now that does sound like a more appropriate summary of the
    problem there.  "The thread is about getting shqq into GNU ELPA,
    but it is being rejected on spurious grounds of a single line of
    code supposedly duplicating the intent of some existing piece of
    code."  The latter is the derail.

Indeed, the whole absurdity of the thread is perhaps best summarized by
the fact that it boils down to one line of code (and alternatively, a
single documentation string).


How about, *first* of all, the latest version of my ELPA patch gets
applied, so there is an *immediate* benefit to Emacs users.  Claiming
that a single line of duplicated code outweighs that would be absurd.

After that, emacs-devel can make whatever change they want to the
package.  My opinion is that it's unethical to whitewash potential
security issues, so I beg you to think hard about them and do what's
necessary to eliminate their possibility in shell-quote-argument.  The
best suggestion I've heard was improving unit tests for that, although a
stricter documentation would also be helpful in my opinion.  You're free
to ignore these suggestions an opinions, in which case I'm not
responsible even if you change shqq to use shell-quote-argument.

In any case, please accept the ELPA patch.  Holding it off any longer
would be absurd unless there's a *serious* issue with it.

Here it is so you don't need to dig it out from the older mails.

Thanks.