From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Emacs Windows barebin distribution Date: Sun, 18 Nov 2012 10:22:09 -0800 Message-ID: References: <4F8ADAFC.9030308@gmail.com> <831unp0xzq.fsf@gnu.org> <837gpj0vyo.fsf@gnu.org> <551F5F9812F347C08746E86B58C59129@us.oracle.com> <6FB41164B73A4DE480BD74B0601BA8FD@us.oracle.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1353262958 29227 80.91.229.3 (18 Nov 2012 18:22:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 18 Nov 2012 18:22:38 +0000 (UTC) Cc: cschol2112@googlemail.com, 'Eli Zaretskii' , emacs-devel@gnu.org, 'Mathias Dahl' To: "'Juanma Barranquero'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 18 19:22:49 2012 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 1Ta9W1-0002U5-MN for ged-emacs-devel@m.gmane.org; Sun, 18 Nov 2012 19:22:45 +0100 Original-Received: from localhost ([::1]:57541 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ta9Vr-0008Eq-D4 for ged-emacs-devel@m.gmane.org; Sun, 18 Nov 2012 13:22:35 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:45907) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ta9Vm-0008Ek-Lg for emacs-devel@gnu.org; Sun, 18 Nov 2012 13:22:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ta9Vj-0006GY-JB for emacs-devel@gnu.org; Sun, 18 Nov 2012 13:22:30 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:18917) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ta9Vg-0006GA-06; Sun, 18 Nov 2012 13:22:24 -0500 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAIIML98023401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 18 Nov 2012 18:22:21 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAIIMKWB016768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Nov 2012 18:22:21 GMT Original-Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAIIMKa0003397; Sun, 18 Nov 2012 12:22:20 -0600 Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 18 Nov 2012 10:22:20 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Ac3FtJngK6uEpIzjTfSfo+qEb5X+eAAADmlA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 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:154923 Archived-At: > > The proposal from Matthias was not a proposal to poll the > > users. He suggested examining the download logs to see > > how much the barebins were picked up. > > Fair enough. Still, that won't also happen on its own, and can be dead > easy, or not, depending on how accessible the logs are for a > sufficiently long interval of time. Which is presumably why Mathias asked "would it be possible to check the access logs?". And it is why my support of the suggestion was qualified with "if feasible", etc. I have no idea how accessible or how accurate the logs are or how easy it would be to check them. > > My argument was against the reasoning that _because_ no one > > has spoken up here there must not be any user interest in this. > > Perhaps you're misinterpreting the reasoning, and it was more like "As > it has been broken for a long time, and we haven't received complains > on emacs-devel (or the bug list), it is reasonable to suppose that > there is no user interest in it." To my knowledge, Eli's mention of it being broken came long after his argument that I responded to. His argument, and his dismissal of Mathias's suggestion was just this - there is nothing here about anything being broken: MD> > Would it be possible to check the access logs to see MD> > how many people actually download the barebin files? EZ> EZ> Since I wrote the mail to which you responded, 7 months EZ> have passed and no one complained. I think by now it EZ> should be clear that no one needs this. It is only that argument that I responded to. > > That's a false argument and suggests a bad attitude, IMHO. > > With all due respect, I think you throw that accusation a bit lightly. I cannot know Eli's attitude, of course, which is why I said that his statement _suggests_ such an attitude to me. It is always a bad idea to attribute motivations or feelings to others, I agree. But to me the rationale he gave fits all too well with such an attitude. That's no proof, and anyway the point is not to prove anything about attitudes. So let me just repeat that, regardless of what the attitudes might be here, we should want to find out what users really use/want/need, and not just suppose that emacs-devel activity reflects that. Regardless of what one can guess wrt attitude, the argument/rationale itself seems clear enough: lack of complaint here indicates that "no one needs this". That was the argument given to reject Mathias's reasonable suggestion of a way to see how many users "actually" use this. And that argument was what I objected to. IOW, not only is it wrong (IMHO) to suppose that emacs-devel activity speaks adequately for user needs. It is also wrong to use that as a reason to immediately reject a suggestion of a way to _really_ know those needs.