From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "John Wiegley" Newsgroups: gmane.emacs.devel Subject: Re: New maintainer Date: Sat, 03 Oct 2015 11:25:54 -0700 Organization: New Artisans LLC Message-ID: References: <560CCEBA.9080607@online.de> <874miapdhs.fsf@openmailbox.org> <8737xuuw2y.fsf@rabkins.net> <87lhbmkrle.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1443896775 17635 80.91.229.3 (3 Oct 2015 18:26:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 3 Oct 2015 18:26:15 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 03 20:26:14 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 1ZiRVc-0008BR-Qp for ged-emacs-devel@m.gmane.org; Sat, 03 Oct 2015 20:26:13 +0200 Original-Received: from localhost ([::1]:39612 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZiRVb-0005RT-UK for ged-emacs-devel@m.gmane.org; Sat, 03 Oct 2015 14:26:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44690) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZiRVW-0005R9-05 for emacs-devel@gnu.org; Sat, 03 Oct 2015 14:26:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZiRVR-0003oy-Vk for emacs-devel@gnu.org; Sat, 03 Oct 2015 14:26:05 -0400 Original-Received: from mail-pa0-x236.google.com ([2607:f8b0:400e:c03::236]:36107) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZiRVR-0003oi-Nc for emacs-devel@gnu.org; Sat, 03 Oct 2015 14:26:01 -0400 Original-Received: by pablk4 with SMTP id lk4so135078614pab.3 for ; Sat, 03 Oct 2015 11:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:subject:in-reply-to:date:organization:message-id :references:user-agent:mail-followup-to:mime-version:content-type; bh=tnq1il0/fwi/tlkXi87+/vTCLpWbnNANpfxUkOtLxls=; b=sJamD3UT3nLqZNltRxIoch9zM8nCX5jiAULMQ6GVhTK14ppMDQEzR9pfuDKlHLGE8c mi/yvf8sSXQLpovZQpsMx+QJmVcouXfyJB5wwTpLQSE9MKDUcnjBei9elRmNXwwJsfsO xmtbCiHLl7eUue+Ca/p2y2roYmziKKRFS/Cc/fj2ghl7sdV/OStdBAN+P9TgQ37GB0E4 9RzysQnlCY6SiELagX0+aC5IegJVtsMLPY/U0j+tfG3TBeCHoc+1WE692yLV6jnOeAV+ dmSsqCllhozfmP0XbLHlGBpsQuU7cO3i6ZxQ0V4QVYLOfXTo2XucBDfrswhtYL9OnTwQ MuyA== X-Received: by 10.66.139.70 with SMTP id qw6mr22653324pab.142.1443896760917; Sat, 03 Oct 2015 11:26:00 -0700 (PDT) Original-Received: from Vulcan.local (76-234-68-79.lightspeed.frokca.sbcglobal.net. [76.234.68.79]) by smtp.gmail.com with ESMTPSA id kh7sm18577695pbc.93.2015.10.03.11.25.58 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 03 Oct 2015 11:25:59 -0700 (PDT) Original-Received: by Vulcan.local (Postfix, from userid 501) id DC02EF0287C3; Sat, 3 Oct 2015 11:25:57 -0700 (PDT) In-Reply-To: (Richard Stallman's message of "Fri, 02 Oct 2015 21:37:45 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (darwin) Mail-Followup-To: emacs-devel@gnu.org X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c03::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:190804 Archived-At: >>>>> Richard Stallman writes: > We measure improvement of GNU Emacs in terms of what it can do as part of > the GNU system. What happens on MacOS or Windows does not count. I can see how this provides clear focus for the FSF in supporting Emacs, no argument here. > We do include support for MacOS and Windows, to the extent people develop > such support and it isn't a problem to include; but we reject any obligation > to support them. Making that an obligation would legitimize those systems -- > and go against our goal, which is to beat them -- and divert effort to > something that doesn't count. OK, as long as the FSF isn't actively getting in the way of such support, to intentionally cripple those systems to make GNU seem better. GNU should *be* better if it is to succeed, not position itself as the best of the worst. > If the Emacs maintainers rejected features that work only on GNU-like > systems, saying "You must add support for Windows and MacOS before we can > install this," that would pressure our contributors to use proprietary > systems (it is unethical even to suggest people use them!). That requirement > would hold back contribution from developers that don't use them. It would > thus impede the improvement of GNU Emacs (which means, making it function > better in GNU). I don't recognize your authority to tell me what is and is not ethical, Richard, and think you should stop using words like "injustice" and "inethical" in your presentations. Not everyone agrees with you, so calling them wrong to paint yourself as right does little service to your cause. If you present the benefits and virtue of GNU-like systems, it gives weight to your message. But standing out by demonizing opponents is a horse that politicians have beat to death, and has never, ever led to lasting success. > Thus, it is unacceptable to require Windows or MacOS support before > installing contributions. A contribution only HAS to work on GNU (but it > should be conditionalized so it does not break Emacs on the other platforms > it doesn't support), but we should try to keep it working on *BSD since that > is usually easy. As for Windows and MacOS support, we can integrate that if > and when someone provides it. > > There is nothing wrong with an Emacs maintainer's writing code to support > for Windows or MacOS. However, if the maintainers have limited time for > Emacs, spending much time supporting secondary platforms could leave the > Emacs maintainers' main job starved for time. That would be a practical > problem, if it happens. Perhaps it won't happen. Again, I can't argue with this as FSF policy. Only that, since I use OS X daily, this is the Emacs I experience, and it colors my perception of how well Emacs is doing. If the experience is great on GNU systems, but awful on OS X, I'll see this as meaning that changes needing to be made. Conversely, I won't notice degradation on GNU systems owing to cross-platform changes, and would require those using such systems to inform me. So there are probably much better candidates than I for achieving the best "GNU Emacs", instead of the broader definition of "Emacs for all supported platforms" that I have in mind. Note too that the latter is very likely what most Emacs users in the world think of when they think of a "better Emacs"; I imagine only a subset of those using Emacs do so to promote GNU more than to edit files. Eli Zaretskii wrote: > So, given this seemingly unsolvable contradiction, what do you, the crowd, > expect of the new maintainer? What "job description", in addition to what > Richard wrote, would you propose if you were tasked with the job of finding > the candidates? E.g., how many hours a week should that person be available > for working on Emacs? Which talents and personal traits should he or she > possess? Etc. etc. I think this is a great next step. We need a proper "job description", including objectives, responsibilities, expectations, and what should define a successful tenure. John