Re: Contributors and maintainers

[Stephen J. Turnbull]

Taylan Ulrich Bayırlı/Kammer writes:

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

I still have no idea why you are so adamant on this point.  This
function is useless unless you're invoking a shell!  Why worry about
Emacs's `shell-quote-argument' when you are assuming the presence of
an attack surface the size of the Great Red Spot?  In other words,
what safety guarantees are you getting from the shell?

 > Maybe emacs-devel should indeed follow Stefan's advice to merge
 > first, then fix,

N.B.  Stefan's advice is double-edged, you know.  It could be directed
at any maintainer of code, including you!  Ie, you could merge Eli's
suggestion into the GELPA version of your package, and fix
`shell-quote-argument' and/or its documentation and test suite later.

 > unless someone insists that there is a *serious*
 > problem.  That might be a very good policy for emacs-devel.

"emacs-devel" manages the core as well as GELPA.  No large, mature
project can follow that policy in the form you propose for the core
(and if Stefan really meant to apply it to shell-quasiquote, I have to
disagree with him -- see below).  Changes to the core have to have
working consensus.  The maintainers -- developers who have
demonstrated commitment to the project as well as the officially
anointed ones -- are quite likely going to end up taking care of your
code.  To enable that without too much effort, they will want
cooperation up front on practices like using existing APIs --
`shell-quote-argument' -- and following existing style -- the
documentation, see Paul Eggert's post for why Eli's approach conforms
and yours doesn't.

For a well-known committer with history in the project, in practice
"working consensus" is often just that one developer.  But because you
are new and unknown, and apparently very young, you will have people
reviewing your code, and somebody else will have to commit it.  There
will need to be a non-trivial consensus to get it in.  N.B.  The point
of that "very young" is that your job status is likely to change and
you may disappear except for a "Thanks for all the fish".  You may say
that won't happen; unfortunately, history shows that a lot of people
who make such promises are unable to keep them.  From experience, we
can't assign a probability as high as 1/2 that it won't happen to you.
But the probability that any of Eli, David[1], Paul, and the cast
of dozens who disagree with you now, and who *will* take
responsibility for your code if you cannot at some later date, will go
away soon is quite low.

Yes, GNU ELPA is probably a different context.  But one unfortunate
fact is that GELPA is at present neither fish nor fowl.  It is part of
GNU Emacs; it says so on the label, and it follows the same policies
with respect to copyright assignment and so on as the core does.  But
most likely the commitment of the maintainers (as defined above) is
much weaker with respect to GELPA than for the core.  If it is
sufficiently weak, "commit, then fix" becomes a very plausible
strategy.  But GELPA may be merely a device to allow modules with low
coupling to the core to have different development cycles, and. really
"it's all just Emacs" (IMO this is likely the way Richard Stallman
would like it to be, for software freedom reasons).  In that case I'd
have to say to be conservative, because package repositories tend to
grow exponentially, and will quickly exceed the ability of maintainers
to keep up.  In the meantime, it *may* be the latter, and (for now)
conservatism is indicated.

Third-party developers want to get their packages out to Emacs users,
of course.  If they don't like the review and bureaucracy and
compromise currently associated with GELPA, they have alternative
efficient ways to do that: github and MELPA.  All three suffer about
equally in terms of discoverability by users compared to the core
(strictly defined).  You lose some True Believers who refuse to get
github accounts if you use github, and users are less likely to have
configured MELPA than GELPA, but the word does get out.  There are a
fair number of popular packages that don't even live in any ELPA, but
are distributed on the EmacsWiki or personal websites.

Footnotes: 
[1]  David will disclaim maintainership even in the informal sense, I
expect.  He's currently on sabbatical, with occasional visits as
gadfly. :-)