From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Omitting Windows-specific parts from infrastructure changes Date: Wed, 21 Jan 2015 21:08:20 +0100 Message-ID: <87y4ovsxqj.fsf@fencepost.gnu.org> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1421870907 16240 80.91.229.3 (21 Jan 2015 20:08:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 21 Jan 2015 20:08:27 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 21 21:08:27 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 1YE1Zi-0001G2-Ij for ged-emacs-devel@m.gmane.org; Wed, 21 Jan 2015 21:08:26 +0100 Original-Received: from localhost ([::1]:50015 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YE1Zh-0005r9-Pz for ged-emacs-devel@m.gmane.org; Wed, 21 Jan 2015 15:08:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37474) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YE1Ze-0005qx-N8 for emacs-devel@gnu.org; Wed, 21 Jan 2015 15:08:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YE1Zd-0002m0-OV for emacs-devel@gnu.org; Wed, 21 Jan 2015 15:08:22 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36922) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YE1Zd-0002lw-LR for emacs-devel@gnu.org; Wed, 21 Jan 2015 15:08:21 -0500 Original-Received: from localhost ([127.0.0.1]:44097 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YE1Zd-0003SS-34; Wed, 21 Jan 2015 15:08:21 -0500 Original-Received: by lola (Postfix, from userid 1000) id AE4AFE0482; Wed, 21 Jan 2015 21:08:20 +0100 (CET) In-Reply-To: <54C00076.1020406@cs.ucla.edu> (Paul Eggert's message of "Wed, 21 Jan 2015 11:39:34 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:181523 Archived-At: Paul Eggert writes: > On 01/21/2015 09:55 AM, Eli Zaretskii wrote: > >> I could simply object to your changes that do a >> partial job, or revert them. > > Wow, is this really a threat to block or revert changes to the Emacs > mainline code, as leverage to force people to do unnecessary > drudgework to help polish up the MS-Windows code? I don't see a threat here. When a change in master breaks functionality for a number of people, the change is reverted as a rule in the projects that I am an active member of. Once the problems have been sorted out, the change may be recommitted. A half-finished change does not just affect the person who ends up fixing the change but everybody else who is working on the platforms broken by a change. Not everyone is in a position to fix every change, and there is no point in having a dozen people frantically working on the same fix. Emacs is developed with a distributed version control system so working on private changes is perfectly possible without affecting the common public repository. Where a change requires involving multiple platform maintainers, it is easily possible to first propose/provide the change in a branch where the respective platform developers able to test or cater for a change can prepare such changes without affecting the usability of the master branch for other developers. > This is starting to get ridiculous. It struck me as ridiculous for quite longer than you it would seem, but then I would guess for quite different reasons. > Let's drop the discussion, as we're not making any progress (quite the > reverse, I'm afraid). While it does not appear that you've changed the stance of either of you two in any way, at least others became aware of the issue and of your inability to come to an agreement. That makes it more likely that others will try contributing to a resolution in case the problem reappears. But since resentment tends to be higher when people not directly affected try effecting a change, that tends to have a worse chance for deescalating the situation than if those directly affected can find a way of cooperating themselves. -- David Kastrup