From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Contributors and maintainers Date: Thu, 22 Oct 2015 03:16:38 +0900 Message-ID: <22055.54918.765691.645283@turnbull.sk.tsukuba.ac.jp> References: <83y4exe71v.fsf@gnu.org> <87zizcfzna.fsf@T420.taylan> <20151021.102719.485566340.wl@gnu.org> <871tcoehk2.fsf@fencepost.gnu.org> <87eggofmy2.fsf@T420.taylan> <83oafse1yg.fsf@gnu.org> <87y4ewdx6a.fsf@T420.taylan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1445491071 21681 80.91.229.3 (22 Oct 2015 05:17:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 22 Oct 2015 05:17:51 +0000 (UTC) Cc: emacs-devel@gnu.org To: taylanbayirli@gmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 22 07:17:39 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zp8Fr-0002fN-LA for ged-emacs-devel@m.gmane.org; Thu, 22 Oct 2015 07:17:35 +0200 Original-Received: from localhost ([::1]:55873 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zp8Fr-0001Q9-8E for ged-emacs-devel@m.gmane.org; Thu, 22 Oct 2015 01:17:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51032) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZoxwL-0006c8-S2 for emacs-devel@gnu.org; Wed, 21 Oct 2015 14:16:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZoxwI-0004rv-IW for emacs-devel@gnu.org; Wed, 21 Oct 2015 14:16:45 -0400 Original-Received: from turnbull.sk.tsukuba.ac.jp ([130.158.96.25]:33990) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZoxwI-0004ri-0r for emacs-devel@gnu.org; Wed, 21 Oct 2015 14:16:42 -0400 Original-Received: from steve by turnbull.sk.tsukuba.ac.jp with local (Exim 4.86) (envelope-from ) id 1ZoxwE-0006ZY-Qi; Thu, 22 Oct 2015 03:16:38 +0900 In-Reply-To: <87y4ewdx6a.fsf@T420.taylan> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta34) "kale" 698a9aa86de4 XEmacs Lucid (x86_64-apple-darwin14.5.0) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: steve@turnbull.sk.tsukuba.ac.jp X-SA-Exim-Scanned: No (on turnbull.sk.tsukuba.ac.jp); SAEximRunCond expanded to false X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 130.158.96.25 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:192344 Archived-At: Taylan Ulrich Bay=C4=B1rl=C4=B1/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:=20 [1] David will disclaim maintainership even in the informal sense, I expect. He's currently on sabbatical, with occasional visits as gadfly. :-)