bug#41276: Acknowledgement ([PATCH 0/9] Various small improvements to EasyPG)

[Jonas Bernoulli]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Jonas Bernoulli <jonas@bernoul.li>
>> Cc: 41276@debbugs.gnu.org
>> Date: Fri, 15 May 2020 13:27:10 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> > A few of the patches in the series don't have commit log messages,
>> 
>> All of the patches do have commit messages.  The mail subject field is
>> used as the commit message subject line, except that the "[PATCH n/m] "
>> has to be removed.
>
> 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

So the complete commit message becomes:

  * lisp/epg-config.el (epg-config--make-gpg-configuration): Fix indentation

Which I though was allowed or even encouraged.  From CONTRIBUTE:

> - If only a single file is changed, the summary line can be the normal
>   file first line (starting with the asterisk).  Then there is no
>   individual files section.

The wording confuses me.  I have decided to interpret it like so (and if
that interpretation is correct, then I suggest that CONTRIBUTE is
updated to use this wording).

> - If only a single file is changed, then the first (and in this case
>   only) individual file entry can at the same time serve as the summary
>   line, provided that the entry fits on a single line.  In this case
>   the summary should begin with an asterisk but not end with a period.
                                              -------
                                      or on the contrary "and"

I added that last sentence because there is some ambiguity that needs to
be resolved, namely:

> - Start with a single unindented summary line explaining the change;
>   do not end this line with a period. [...]

> - Some commenting rules in the GNU coding standards also apply
>   to ChangeLog entries: they must be in English, and be complete
>   sentences starting with a capital and ending with a period (except
>   the summary line should not end in a period).

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
`----