Re: Contributors and maintainers

[Taylan Ulrich Bayırlı/Kammer]

Eli Zaretskii <address@hidden> writes:

>> From: address@hidden (Taylan Ulrich Bayırlı/Kammer)
>> Date: Wed, 21 Oct 2015 14:03:33 +0200
>> Cc: address@hidden
>> 
>> 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.
>
> I don't think things happen like that around here.  But the
> description is so vague and devoid of any specific details that it's
> easy to misinterpret.  I would first and foremost suspect some
> misunderstanding.  After all, for most people here, myself included,
> English is not their first language, so nuances could sometimes lead
> to misunderstandings.  Can we have the person(s) who came up with this
> description please speak up and point to specific discussions and
> specific messages that could lead to such conclusions, and perhaps
> suggest ways for changing the dynamics here away of that?

I'm very sure they don't want to deal with this.

I can ask them if you want absolute confirmation.

>> 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.
>
> Is that what this is about? that you don't want to make that change
> yourself, but agree to someone else making it?  If so, then I think we
> will gladly provide that service, and there are no more obstacles for
> admitting the package.

No it's not "what this is about."  Given the current lack of safety
guarantees in shell-quote-argument, I actively do not want it to be used
in shqq, or any other place where it may receive data from an untrusted
input source.

(The patch I provided for shell-quote-argument changes that, since it
formalizes safety guarantees at least in documentation.  Although, a
stricter solution like comprehensive unit tests would in turn be much
better than my mere documentation patch.)

But since we're in a deadlock regarding that topic, I say take my code
as is, first of all.

Then, having read all my reasoning and attempts to convince that
shell-quote-argument should not be used as is in places where it may
receive data from untrusted input sources, you're free to make any
changes to it.  I gave my suggestion on what change to avoid; if that
suggestion is disagreed with despite my best efforts to convince of it,
then obviously there's nothing more I can do.

Long story short, it's not that I "don't want to make that change
myself, but agree to someone else making it"; it's rather so that I
"disapprove of the change, thus won't do it myself, but ran out of
energy in trying to convince others not to do it."


One way or another, please as a first step apply the patch, since that
has clearly positive utility.  Maybe emacs-devel should indeed follow
Stefan's advice to merge first, then fix, unless someone insists that
there is a *serious* problem.  That might be a very good policy for
emacs-devel.  (With an obvious exception for a few initial feedback
round-trips.)

Taylan