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: Omitting Windows-specific parts from infrastructure changes Date: Mon, 19 Jan 2015 20:32:12 +0200 Message-ID: <83egqqy637.fsf@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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1421692383 30697 80.91.229.3 (19 Jan 2015 18:33:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 Jan 2015 18:33:03 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 19 19:33:02 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 1YDH8H-0002sK-OA for ged-emacs-devel@m.gmane.org; Mon, 19 Jan 2015 19:33:01 +0100 Original-Received: from localhost ([::1]:39272 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDH8G-0002LA-PI for ged-emacs-devel@m.gmane.org; Mon, 19 Jan 2015 13:33:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39534) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDH83-0002L5-FF for emacs-devel@gnu.org; Mon, 19 Jan 2015 13:32:48 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YDH7z-0002QP-GC for emacs-devel@gnu.org; Mon, 19 Jan 2015 13:32:47 -0500 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:49517) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDH7z-0002QG-84 for emacs-devel@gnu.org; Mon, 19 Jan 2015 13:32:43 -0500 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NIF00O00S6GYN00@mtaout25.012.net.il> for emacs-devel@gnu.org; Mon, 19 Jan 2015 20:27:45 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NIF00LR1SM92750@mtaout25.012.net.il>; Mon, 19 Jan 2015 20:27:45 +0200 (IST) In-reply-to: <54BD4657.3010202@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.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:181446 Archived-At: > Date: Mon, 19 Jan 2015 10:00:55 -0800 > From: Paul Eggert > CC: emacs-devel@gnu.org > > Eli Zaretskii wrote: > > Doing nothing means leaving the parts > > you side-stepped to bit-rot and generate bug reports, > > Nothing is rotting here, as the code is working. It is working because I cleaned it up. It didn't work before that, and in some places didn't use the new infrastructure, but the old one. Leaving this as it is will eventually produce maintenance headaches we are better without. > No bug reports have been generated because of this longstanding > practice. As the benefits of the proposed change to the practice do > not appear to exceed the costs, I'd rather leave things be. The costs are minuscule: just a short notice posted here. So I really don't understand why you refuse to honor such a simple and reasonable request for some minimal help to your fellow developers. Can you explain? > > Leaving it to others to discover the places that were omitted, without > > any guidance as to how to identify them is too error-prone > > No special guidance is needed, as the search heuristics are obvious. For > example, if the change involves replacing strcat with stpcpy, look at all uses > of strcat in the modules you're interested in. All I'm asking is to post a short note to that effect when such changes are done in the future. Without that, what needs to be done is not easily discoverable, since we don't usually document that in our logs. In contrast, someone who does this change should have no difficulty either describing the search heuristics or even pointing out the places where the changes need to be followed-up.