About ChangeLog Fwd: [fricas/fricas] prevent error message leakage in "ker2trigs" (PR #94)

[oldk1331]

I'd like to discuss about the status of ChangeLog.

I don't like to include ChangeLog recently because my patches
are reviewed in undetermined order, with ChangeLog entries in
the patch, it will surely get merge/rebase conflict. Also the
date would be inaccurate.

Of course I can manually add ChangeLog entries after patch
review and before I commit it.

But I'd like to have a discussion about current ChangeLog policy.

Is manually updated ChangeLog still useful?
Is current git commit message good enough?
Shall we go for auto-generated ChangeLog from git commit before release?
Shall we go for a more informative commit message? (say kernel style)

- Qian

-------- Forwarded Message --------
Subject: Re: [fricas/fricas] prevent error message leakage in
"ker2trigs" (PR #94)
Date: Wed, 29 Jun 2022 02:58:07 -0700
From: hebisch <notifi...@github.com>
Reply-To: fricas/fricas
<reply+ADMRJBJVIH5YDFQY3T...@reply.github.com>
To: fricas/fricas <fri...@noreply.github.com>
CC: Qian Yun <oldk...@gmail.com>, State change
<state_...@noreply.github.com>



On Tue, Jun 28, 2022 at 06:55:14PM -0700, Qian Yun wrote:
> Merged #94 into master.

When mereging please do not forget ChangeLog entries.

--
Waldek Hebisch

—
Reply to this email directly, view it on GitHub
<https://github.com/fricas/fricas/pull/94#issuecomment-1169781471>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMRJBIHUWDSMY7GFZEWKR3VRQM27ANCNFSM5ZGPHLLA>.
You are receiving this because you modified the open/close state.Message
ID: <fricas/fricas/pull/94/c1169...@github.com>

[Ralf Hemmecke]

On 29.06.22 12:33, oldk1331 wrote:
> I'd like to discuss about the status of ChangeLog.
>
> I don't like to include ChangeLog recently because my patches
> are reviewed in undetermined order, with ChangeLog entries in
> the patch, it will surely get merge/rebase conflict. Also the
> date would be inaccurate.

That is also my opinion. The ChangeLog file is a needless complication
if we work with git and shuffle the order of commits during development.
One anyway gets everything with "git log" or the short form "git log
--oneline". There are even programs that generate nicer output.

> Of course I can manually add ChangeLog entries after patch
> review and before I commit it.

I think that is an unnessary burden and adds no benefit. The information
is just doubled from the commit message.

What can be done is to generate a ChangeLog for a release. However, in
recent commits Waldek anyway creates a list of entries for ug15.htex.
The information for that can be retrieved from "git log". We should make
sure that the log-messages are nice and say why a certain commit was
done. But there is no need for our current ChangeLog file anymore.

Ralf

[Waldek Hebisch]

On Wed, Jun 29, 2022 at 06:33:21PM +0800, oldk1331 wrote:
> I'd like to discuss about the status of ChangeLog.
>
> I don't like to include ChangeLog recently because my patches
> are reviewed in undetermined order, with ChangeLog entries in
> the patch, it will surely get merge/rebase conflict. Also the
> date would be inaccurate.
>
> Of course I can manually add ChangeLog entries after patch
> review and before I commit it.

Yes, that is the way to go.

> But I'd like to have a discussion about current ChangeLog policy.
>
> Is manually updated ChangeLog still useful?
> Is current git commit message good enough?
> Shall we go for auto-generated ChangeLog from git commit before release?
> Shall we go for a more informative commit message? (say kernel style)

Important advantage of ChangeLog is that it contains relevant
information in reasonably terse way. Relevant means modified
files and meaningful identification of change. Note that
ChangeLog does not contain info about non-critical files,
that is documentation and tests.

IMO trying to auto-generate ChangeLog from git info would decrease
quality of ChangeLog. IMO spending a little extra effort is
worth it.

I am against longer log messages. There is really no upper
bound on amount of extra info or explanations that somebody
may need/want. And the purpose of log is to allow filtering
which works well with terse messages.

--
Waldek Hebisch