Re: Contributors and maintainers

[John Wiegley]

>>>>> Taylan Ulrich "Bayırlı/Kammer" <address@hidden> writes:

> 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.

Is this really the core issue we're debating? Then let me respond to it: **We
do not agree with your assessment of shell-quote-argument's lack of safety,
and require tests from you to demonstrate this is the case**. The ball is now
officially in your court.

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

And my response is: No. We will not take your code, because we do not want it
in its present form.

> One way or another, please as a first step apply the patch, since that has
> clearly positive utility.

It is not clearly positive to *us*. "Clearly" is a subjective assessment.

> 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.

Absolutely not. We do not have time to play catch up, and to retroactively fix
bugs we allow in because submitters want their code committed right away. We
try to filter what we accept *before* it goes in, so we can move on to other
things.

"Check in first, fix later" is a policy I have personally seen destroy code
bases at professional organizations, where people were paid 40 hours a week to
keep the code maintained. Now imagine this at Emacs-scale, and you will see
it's untenable as a strategy.

If you're upset because we don't want your submission in its current form,
there isn't much I can do about that. You know what needs to be done to fix
it. If you don't want to fix it, or don't believe it needs fixing, use MELPA.

There is really nothing more to say on this subject, so I would appreciate
closing the matter until new code is produced.

John