From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Omitting Windows-specific parts from infrastructure changes Date: Thu, 22 Jan 2015 09:20:09 -0500 Message-ID: References: <838uh32gpg.fsf@gnu.org> <54B9D960.1000001@cs.ucla.edu> <834mrp24b1.fsf@gnu.org> <54BBF6E7.3090802@cs.ucla.edu> <83a91gymld.fsf@gnu.org> <54BC08B2.8070302@cs.ucla.edu> <837fwjzx5f.fsf@gnu.org> <54BC18B9.50202@cs.ucla.edu> <83y4oyycz8.fsf@gnu.org> <54BD4657.3010202@cs.ucla.edu> <83egqqy637.fsf@gnu.org> <54BD81C4.1070109@cs.ucla.edu> <833875xvin.fsf@gnu.org> <54BEC86A.7060605@cs.ucla.edu> <83d268w2w9.fsf@gnu.org> <54BFE299.3060600@cs.ucla.edu> <833874vx1e.fsf@gnu.org> <54C00076.1020406@cs.ucla.edu> <831tmnx4e6.fsf@gnu.org> <87egqnhnae.fsf@fencepost.gnu.org> <83vbjzv5fe.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1421936454 9315 80.91.229.3 (22 Jan 2015 14:20:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 22 Jan 2015 14:20:54 +0000 (UTC) Cc: David Kastrup , emacs-devel@gnu.org, eggert@cs.ucla.edu To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 22 15:20:49 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 1YEIcq-0001j5-Hl for ged-emacs-devel@m.gmane.org; Thu, 22 Jan 2015 15:20:48 +0100 Original-Received: from localhost ([::1]:53488 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEIcp-000108-Ow for ged-emacs-devel@m.gmane.org; Thu, 22 Jan 2015 09:20:47 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36892) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEIcO-0000zZ-J3 for emacs-devel@gnu.org; Thu, 22 Jan 2015 09:20:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YEIcK-0007Pi-M4 for emacs-devel@gnu.org; Thu, 22 Jan 2015 09:20:20 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:43339) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEIcD-0007MH-W8; Thu, 22 Jan 2015 09:20:10 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwPAOwQflSnWBWM/2dsb2JhbABRCoMHg2CFWsUdBAICgSQXAQEBAQEBfIQDAQEDAVYjBQsLNBIUGA0kiEoJ1lkBAQEBBgEBAQEekBNcB4RIBYsBpiaEGSGCdwEBAQ X-IPAS-Result: AjwPAOwQflSnWBWM/2dsb2JhbABRCoMHg2CFWsUdBAICgSQXAQEBAQEBfIQDAQEDAVYjBQsLNBIUGA0kiEoJ1lkBAQEBBgEBAQEekBNcB4RIBYsBpiaEGSGCdwEBAQ X-IronPort-AV: E=Sophos;i="5.07,502,1413259200"; d="scan'208";a="108466442" Original-Received: from 167-88-21-140.cpe.teksavvy.com (HELO pastel.home) ([167.88.21.140]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Jan 2015 09:20:09 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 475EA2A58; Thu, 22 Jan 2015 09:20:09 -0500 (EST) In-Reply-To: <83vbjzv5fe.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 22 Jan 2015 05:51:33 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:181598 Archived-At: I don't want to get into this discussion, but in case people wonder where I stand, I fully agree with Eli's position below. Stefan > No, we are talking about making changes in infrastructure used by all > platforms. Once someone decides to make such changes, making > good-faith effort to do that in all parts of Emacs is part of the job. > It could be done either by actually making those changes all over, or > by asking platform maintainers to do the parts related to their > platforms. In the latter case, the platform maintainers should have > enough information about the proposed change to be able to do their > parts without investing too much time and effort where the initiator > can help them avoid that. > For example, in the recently discussed changeset that uses CALLN for > some C-level calls to Lisp APIs, the information that should be passed > to platform maintainers is how to identify the offending calls. This > information is clear to the person who initiated the change and it's > possible to describe it in a sentence or two. I have hard time > understanding how this kind of requirement could be described as > impossible or hard to comply.