From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Patches with independent changes Date: Fri, 24 Jan 2014 08:43:19 -0800 Organization: UCLA Computer Science Department Message-ID: <52E29827.7060209@cs.ucla.edu> References: <8361pbg5vy.fsf@gnu.org> <52E08D31.3080801@cs.ucla.edu> <8338kffj7m.fsf@gnu.org> <52E0A0ED.4020601@cs.ucla.edu> <83y526el6z.fsf@gnu.org> <52E18EC0.7090302@cs.ucla.edu> <83lhy5ests.fsf@gnu.org> <52E2277B.9000205@cs.ucla.edu> <83bnz1eo1x.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1390581817 23067 80.91.229.3 (24 Jan 2014 16:43:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 Jan 2014 16:43:37 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 24 17:43:45 2014 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 1W6jr4-0005Av-G7 for ged-emacs-devel@m.gmane.org; Fri, 24 Jan 2014 17:43:42 +0100 Original-Received: from localhost ([::1]:47608 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6jr4-0007dQ-2Y for ged-emacs-devel@m.gmane.org; Fri, 24 Jan 2014 11:43:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43290) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6jqu-0007UJ-L7 for emacs-devel@gnu.org; Fri, 24 Jan 2014 11:43:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W6jqp-00030a-P9 for emacs-devel@gnu.org; Fri, 24 Jan 2014 11:43:32 -0500 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:53179) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6jqj-0002yp-Js; Fri, 24 Jan 2014 11:43:21 -0500 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id C8663A60005; Fri, 24 Jan 2014 08:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7c234wl0i9a; Fri, 24 Jan 2014 08:43:19 -0800 (PST) Original-Received: from [192.168.1.9] (pool-108-0-233-62.lsanca.fios.verizon.net [108.0.233.62]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 93421A60003; Fri, 24 Jan 2014 08:43:19 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: <83bnz1eo1x.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 131.179.128.62 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:169019 Archived-At: [retitling from "Changes in update-game-score.c"] Eli Zaretskii wrote: > chmod is documented to be able to return both negative and positive values Really? Where is it documented to do that? It's not documented that way in the POSIX documentation for chmod, or in the Gnulib documentation of chmod porting hassles; see and , respectively. Even if you're correct, which I doubt, trunk bzr 116116 would still be an example of what you're calling a "sumo" patch -- a patch containing multiple independent changes. One change addresses WINDOWSNT's lack of fchmod. Another addresses the perhaps-hypothetical issue that chmod can return positive values. So regardless, that patch does not follow the rule that patches should fix just one bug and should not make independent changes. Insisting on such a rule would be silly, anyway. We don't follow that rule and we never have, and we shouldn't impose it now. Obviously there are advantages to putting independent changes in separate patches and in many cases we should do that, but an extremist insistence of this principle in all cases would significantly increase our maintenance burden for little or no benefit.