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: master 5022e27: ; Do not overwrite preexisting contents of unread-command-events Date: Sat, 08 Aug 2015 13:18:32 +0300 Message-ID: <837fp6qe13.fsf@gnu.org> References: <20150804124300.13374.78396@vcs.savannah.gnu.org> <2qy4hr840o.fsf@fencepost.gnu.org> <87r3nj3vbw.fsf@fencepost.gnu.org> <87k2t6i3hu.fsf@fencepost.gnu.org> <838u9mqh4t.fsf@gnu.org> <87fv3ui0h3.fsf@fencepost.gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1439029143 27228 80.91.229.3 (8 Aug 2015 10:19:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 8 Aug 2015 10:19:03 +0000 (UTC) Cc: rgm@gnu.org, emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 08 12:18:55 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 1ZO1DI-0002y9-L2 for ged-emacs-devel@m.gmane.org; Sat, 08 Aug 2015 12:18:52 +0200 Original-Received: from localhost ([::1]:52448 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZO1DH-0001i2-Tm for ged-emacs-devel@m.gmane.org; Sat, 08 Aug 2015 06:18:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58270) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZO1D6-0001hw-Bn for emacs-devel@gnu.org; Sat, 08 Aug 2015 06:18:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZO1D5-0000D7-2K for emacs-devel@gnu.org; Sat, 08 Aug 2015 06:18:40 -0400 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:36255) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZO1D1-0008VF-1Y; Sat, 08 Aug 2015 06:18:35 -0400 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NSR00400DEF1L00@mtaout25.012.net.il>; Sat, 08 Aug 2015 13:14:42 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NSR005K0DSHE600@mtaout25.012.net.il>; Sat, 08 Aug 2015 13:14:42 +0300 (IDT) In-reply-to: <87fv3ui0h3.fsf@fencepost.gnu.org> 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:188606 Archived-At: > From: David Kastrup > Cc: rgm@gnu.org, emacs-devel@gnu.org > Date: Sat, 08 Aug 2015 11:38:32 +0200 > > Well, the question is just what this entry should entail. Every changed > function and file? Yes. > That will be a rather large entry. It's not a problem. We have our share of such large entries already. > Apart from that I don't think I need to "wait for the update to > ChangeLog.2" since the complaint was that the log message was formatted > in a way where it would not even cause an entry to ChangeLog.2. So it > doesn't really seem to matter all that much just when I'll update > ChangeLog.2 manually. Right. > Well, the changes are mostly of the "similar minor change" kind, namely > not completely obeying the same description. Nevertheless, I think it should be possible to come up with some text that would allow you to have a single entry for all of those changes. > The main problem I have is that the invested work and the resulting > space in the ChangeLog is not going to save anybody any time or effort > since we are not talking about a feature here or normally user-visible > changes in semantics. And it's not particular to any package/feature > either. It's not the kind of change we are maintaining a ChangeLog file > separate from commit messages for. I think our rule is to have ChangeLog entries for all non-trivial changes whose description carries significant information. Basically, anything that people might want looking up in order to understand why was the change done. I think your changes qualify. > The reason I made that simple commit message really wasn't "oh, I'm too > lazy to do a proper one" but rather "this would not even make sense". > Obviously other developers disagree after the fact so I'll "fix" it. I > just have a hard time doing a fix that does not feel like making the > situation worse than it is already. Something like this: * file1 (func1, func2, func3): * file2 (func4, func5): * file3 (func6, func7, func8, func9): Minor improvements in how events are added to unread-command-events. shouldn't make things worse, and should be fairly easy to write, I think.