From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: taylanbayirli@gmail.com (Taylan Ulrich =?utf-8?Q?Bay=C4=B1rl=C4=B1?= =?utf-8?Q?=2FKammer?=) Newsgroups: gmane.emacs.devel Subject: Re: Contributors and maintainers Date: Wed, 21 Oct 2015 18:05:33 +0200 Message-ID: <87y4ewdx6a.fsf@T420.taylan> 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> 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 1445443563 3819 80.91.229.3 (21 Oct 2015 16:06:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 21 Oct 2015 16:06:03 +0000 (UTC) Cc: dak@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 21 18:05:53 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 1ZovtX-0004kz-GX for ged-emacs-devel@m.gmane.org; Wed, 21 Oct 2015 18:05:43 +0200 Original-Received: from localhost ([::1]:52485 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZovtW-0007xU-Ui for ged-emacs-devel@m.gmane.org; Wed, 21 Oct 2015 12:05:42 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33680) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZovtS-0007xI-AU for emacs-devel@gnu.org; Wed, 21 Oct 2015 12:05:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZovtQ-0004HU-UU for emacs-devel@gnu.org; Wed, 21 Oct 2015 12:05:38 -0400 Original-Received: from mail-wi0-x236.google.com ([2a00:1450:400c:c05::236]:33210) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZovtQ-0004HO-LC; Wed, 21 Oct 2015 12:05:36 -0400 Original-Received: by wijp11 with SMTP id p11so102374151wij.0; Wed, 21 Oct 2015 09:05:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:content-transfer-encoding; bh=+0f2oMaFrr6RS5+SH0wodu2fIX/PIgWaQtMpFTMuhz8=; b=z2PNBHGl2uwzWDWgtQIXAHgcxXm3Q3+sxfATA4Zxe3/XT5BaQhrqjIEB4KAHJ22pxT bNCe0RVa61qmF1nKuKcAmb3Y6gzDHLyDH0A59VPzJ6O3Y45SuA73TNPA95lmdMXKKbGK 3zthk/NxjV/+14TD+uxhWJLZhr7nMKg3IPSAqRU52bNmFM7BtPR79bwsA1fIsW9Fc0WU DKnB3PdVRZdvD1uo/iakmC/Fz0llc7VjA1Kaj1patRUBBiJRyGXSH1ENobA2PlOJBbRa RWQEmRlPt7v4KQvYuNcDOxpSlVEfojzSiyA3Fh2pm3W4gnYEWoebvCOCTbCyDxQemXwi +Z7Q== X-Received: by 10.194.77.79 with SMTP id q15mr13597053wjw.102.1445443535884; Wed, 21 Oct 2015 09:05:35 -0700 (PDT) Original-Received: from T420.taylan ([2a02:908:c32:4740:221:ccff:fe66:68f0]) by smtp.gmail.com with ESMTPSA id it4sm11267694wjb.0.2015.10.21.09.05.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Oct 2015 09:05:34 -0700 (PDT) In-Reply-To: <83oafse1yg.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 21 Oct 2015 17:22:15 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::236 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:192292 Archived-At: Eli Zaretskii writes: >> From: taylanbayirli@gmail.com (Taylan Ulrich Bay=C4=B1rl=C4=B1/Kammer) >> Date: Wed, 21 Oct 2015 14:03:33 +0200 >> Cc: emacs-devel@gnu.org >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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