From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: File names in ChangeLog entries Date: Thu, 02 Dec 2021 10:33:41 +0200 Message-ID: <83tufrpfru.fsf@gnu.org> References: <831r2xt32t.fsf@gnu.org> <83ilw8sa9j.fsf@gnu.org> <835ys8s1gg.fsf@gnu.org> <87czmgruyc.fsf@gnuvola.org> <83h7bsqfxh.fsf@gnu.org> <837dcnqy3q.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38003"; mail-complaints-to="usenet@ciao.gmane.io" Cc: stefan@marxist.se, ttn@gnuvola.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 02 09:35:44 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mshZ9-0009cm-Ne for ged-emacs-devel@m.gmane-mx.org; Thu, 02 Dec 2021 09:35:43 +0100 Original-Received: from localhost ([::1]:42116 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mshZ8-0004QW-DS for ged-emacs-devel@m.gmane-mx.org; Thu, 02 Dec 2021 03:35:42 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:60892) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mshXR-0003i0-8X for emacs-devel@gnu.org; Thu, 02 Dec 2021 03:33:57 -0500 Original-Received: from [2001:470:142:3::e] (port=34700 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mshXP-0002XF-LD; Thu, 02 Dec 2021 03:33:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=JGN18euby8HOByRyVWn/AqZS2LDuugVxOH3BX5nOF8A=; b=ElZqheCWJiE+ zJ0/QxBKK0hdXC/C8OXAfste2q6IhXnk8rm9bezfpUSHW85QhPmtbw9vXZxFnh4UYSYNVxb7M/TfS dyJDOLzGT8ydR/QSqVk/sgHl8qiQGlmiqGT6SLM+gxrT1fxSqY0Q/fzKvr3mNNrHc5OKYg5QWn06f mMjwH2bUSGQw6vdgAHCSIbBeaRHNYDrmzCPL7FqSQgSkJceqNjTHgD7hVBBHiG+5TIpY1fNtEsjY/ 8h6a+nOGEswWkhut7OCzGY/zgheFa7pP4u96d2bVI/mNvSyH6o2gKdfH7S+NL8HqUT7LyYUeLF6lM Bob+29FsnlzB/RNQlO2OvA==; Original-Received: from [87.69.77.57] (port=2573 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mshXP-00010v-Bc; Thu, 02 Dec 2021 03:33:55 -0500 In-Reply-To: (message from Stefan Monnier on Thu, 02 Dec 2021 02:34:32 -0500) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:280726 Archived-At: > From: Stefan Monnier > Cc: stefan@marxist.se, ttn@gnuvola.org, emacs-devel@gnu.org > Date: Thu, 02 Dec 2021 02:34:32 -0500 > > > For > > example, this summary: > > > > * lisp/emacs-lisp/subr-x.el (with-memoization): New macro > > > > could have been more economically written as > > > > New macro 'with-memoization' > > > > or, if you insist on mentioning the file, as > > > > New macro 'with-memoization' in subr-x.el > > I'd prefer > > subr-x (with-memoization): New macro > > which is closer to the rest of our conventions. Our conventions are for the detailed descriptions of the changes. the summary line is supposed to be human-readable free text, not machine-readable text in rigid format. What you prefer is not bad, but it is less readable by humans, IMO. > Having the subsystem > info always at the beginning is important to be able to visually scan > many commits quickly without having to read&parse&understand each and > every summary text. It's even more important when several commits in > a row affect the same subsystem in which case the scanning is made even > faster when all those commits put the subsystem info at the same place. Those are your personal goals, due to your particular usage of these parts of the log messages. But that's not the only use of them, and not even the main one. > > And in this example: > > > > * lisp/emacs-lisp/cl-generic.el: Try and fix bug#49866 > > > > (cl-generic-generalizers): Remember the specializers that match > > a given value. > > (cl--generic-eql-generalizer): Adjust accordingly. > > > > * test/lisp/emacs-lisp/cl-generic-tests.el (cl-generic-test-01-eql): > > Add corresponding test. > > > > the file name in the summary is entirely redundant, since fixing a bug > > is not necessarily related to a particular file (as the rest of the > > log message clearly shows). > > I don't understand what you mean: the patch basically only touches > `cl-generic.el`. No, it also changes the test suite. > Indeed, this discussion is related to the generation of the ChangeLog > and to the fact that I have completely and totally stopped looking at > them, so I'm beginning to doubt the usefulness of > keeping/generating them. [ I'm curious to know who uses them still. ] We had this discussion. There are enough people who want to have a usable ChangeLog in several situations. Therefore we decided to generate them when a release is tarred. Restarting this discussion because the ChangeLog format is not to the liking of some of us sounds to me like a salami tactics: first we take Manhattan, then we take Berlin. Let's instead stick to our decisions. > Is there a chance that others might be willing to accommodate my request > to always include some subsystem info in the summary line in return? I don't know. For me, it'd be an annoyance: I usually try very hard to come up with a short but detailed enough summary, which isn't easy in some cases. Having to "waste" some of the precious space on some subsystem info would make this a lot harder.