From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Patches with independent changes Date: Sun, 26 Jan 2014 05:47:15 +0200 Message-ID: <83d2jfbe0s.fsf@gnu.org> 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> <52E29827.7060209@cs.ucla.edu> <83ha8tcb4z.fsf@gnu.org> <52E2EA7B.2080501@cs.ucla.edu> <83fvoccyqt.fsf@gnu.org> <52E3EDE1.9050709@cs.ucla.edu> <83mwikas8w.fsf@gnu.org> <52E42561.4080807@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1390708056 13518 80.91.229.3 (26 Jan 2014 03:47:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 26 Jan 2014 03:47:36 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 26 04:47:43 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 1W7GhC-00013N-Jv for ged-emacs-devel@m.gmane.org; Sun, 26 Jan 2014 04:47:42 +0100 Original-Received: from localhost ([::1]:53404 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7GhC-0000xd-1B for ged-emacs-devel@m.gmane.org; Sat, 25 Jan 2014 22:47:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46544) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7Gh4-0000xN-FD for emacs-devel@gnu.org; Sat, 25 Jan 2014 22:47:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W7Ggz-000282-82 for emacs-devel@gnu.org; Sat, 25 Jan 2014 22:47:34 -0500 Original-Received: from mtaout24.012.net.il ([80.179.55.180]:39215) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7Ggy-00027v-RO for emacs-devel@gnu.org; Sat, 25 Jan 2014 22:47:29 -0500 Original-Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0MZZ00N00NYC1J00@mtaout24.012.net.il> for emacs-devel@gnu.org; Sun, 26 Jan 2014 05:47:08 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZZ00ICZP6KZR70@mtaout24.012.net.il>; Sun, 26 Jan 2014 05:47:08 +0200 (IST) In-reply-to: <52E42561.4080807@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.180 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:169103 Archived-At: > Date: Sat, 25 Jan 2014 12:58:09 -0800 > From: Paul Eggert > CC: emacs-devel@gnu.org > > Eli Zaretskii wrote: > > otherwise the build would have failed when compiler warnings are > > turned on and used as errors. > > That would have been odd, as other static variables in Emacs are > declared and set but never used (e.g., category_table_version) and > evidently these builds are not failing. It's certainly OK to clean up > the glitches, but such cleanups are independent changes. They are not independent. A variable that becomes unused as result of a change should be removed as part of that change. > > Then any number of patches can be installed in a single commit, > > because they are all "related" -- after all, they are all about Emacs. > > No, that's too broad. Patches should contain changes that are more > closely-related than that. That's the gist of our disagreement: how close that relation should be. Using vague terminology, such as "related", doesn't solve it. > > you cannot chmod a file that is open ... the chmod call will fail. > > Where is this documented? Does the problem occur if any process has the > file open, or only if the current process has it open? What is errno > after the failure? This problem does not occur on POSIXish platforms; > if it happens under Microsoft Windows the incompatibility should be > documented (in Gnulib, if the problem is generic to GNU applications). Then document it, please. Gnulib documentation is not of interest here. > > the fact that the problem could have been solved in more than > > one way doesn't mean there are multiple changes involved. > > True, but if the problem could have been solved in a simpler way that > involved fewer changes, then multiple changes were most likely present. It's not simpler. > Come to think of it, why is that chmod needed at all in WINDOWSNT? The > file is already readable and writeable, so as I understand it chmod 644 > is therefore a no-op on that platform. If so, the attached patch would > have been simpler yet, no? Removal of this code _could_ have constituted an additional change unrelated to the original bug. In any case, we don't want to consider changes that aren't bugfixes at this time. The change I made restored code that was there in the first place. Any improvements can be considered at a later date.