GNU bug report logs - #41276
[PATCH 0/9] Various small improvements to EasyPG

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jonas Bernoulli <jonas <at> bernoul.li>
Cc: 41276 <at> debbugs.gnu.org
Subject: bug#41276: Acknowledgement ([PATCH 0/9] Various small improvements to EasyPG)
Date: Fri, 15 May 2020 20:42:11 +0300

> From: Jonas Bernoulli <jonas <at> bernoul.li>
> Cc: 41276 <at> debbugs.gnu.org
> Date: Fri, 15 May 2020 18:56:06 +0200
> 
> > Right, that's the header line.  I meant the part after it, which
> > mentions the file(s) and the function(s) where the changes are done.
> 
> I can only see one commit that lacks a commit message body in addition
> to the commit message summary line.
> 
> [I am a little confused because while I agree that I failed to follow
> the conventions and need to fix that, you do talk about multiple commits
> that have this particular defect while I can see only a single commit,
> which might potentially have that defect.]
> 
> The subject of the respective mail is:
> 
>   [PATCH 3/9] * lisp/epg-config.el (epg-config--make-gpg-configuration): Fix indentation

Ah, okay.  Please forgive me, I almost never read the Subject line,
and expect all the important stuff to be in the body.  So I will blame
Git in this case ;-)

> However I feel it would make more sense for the first rule to override
> the second.  From recent commits it looks like you and some others seem
> to agree with me:
> 
> ,----
> | ; * src/xdisp.c: Improve the introductory commentary.
> `----
> 
> but Stefan does not:
> 
> ,----
> | * lisp/emacs-lisp/pcase.el (pcase--fgrep): Look inside vectors
> `----

You need to keep in mind how these are used: they are copied into the
ChangeLog file we generate when we are about to release a new Emacs
version.  So if the header line is followed by a series of
ChangeLog-formatted entries, it should not end in a period, but when
the header line is _itself_ a ChangeLog-formatted entry, then it
should follow the ChangeLog rules, which is that every entry shall end
in a period.  IOW, the second rule in this case overrides the first.

And while we are at that: please don't follow examples like this:

   * foobarbz/barfooquux/baz.xx (some_long_function_name):

   Fix this and that.

That is, if the log entry takes more than one line, do NOT try to
avoid adding the header line by "reusing" the first line of the entry
as a header line, and leaving an empty line between the first line of
the log message and the rest of them.  The reason is still the same:
this will look awkward, to say the least, in the generated ChangeLog.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.