Re: ChangeLogs in commit messages

[Gary Benson <gbenson@redhat.com>]

Joel Brobecker wrote:
> > Do you mean #4 (changelog entries with no path/author-date) or are
> > you proposing new option #5 (no changelog in the commit message at
> > all)?  #5 would suit me too.
> 
> No, I strongly object to #5. The ChangeLog entries are part of the
> email to be sent along with the patch to be reviewed, We had that
> discussion many many years ago, and at the time, people wanted the
> CL entry in the email, rather than as a diff.

This discussion is starting to blur the lines between "what is in the
commit message" and "what is in the gdb-patches email".  Right now,
the two are the same, especially if you use git-send-email, but I
don't think git-send-email convenience is a valid reason to say that
ChangeLog entries need to be in the commit message.  If we wanted a
situation where gdb-patches emails have ChangeLog entries but commit
messages do not then we could surely script that.

> And finally, I find the CL entry to be useful to have when I review
> revision logs.

Noted.

My work on GDB mostly involves _generating_ commits, so I have a
natural bias towards removing things that make that difficult (and
ChangeLogs are an easy target).  I do recognise, however, that some
people's work also involves _consuming_ commits (for creating release
branches, or for distro integration) so when I hear Joel and Sergio
stating the cases for a) ChangeLog files to exist, and b) ChangeLog
entries to be included in commit messages I have to admit that their
arguments carry more weight than my "everything would be so much more
convenient for me if ChangeLogs went away".  So I think we should
stop discussing the removal of ChangeLogs, in this thread anyway.

Andreas Arnez pointed out that Joel previously mentioned generating
the actual ChangeLog files from the commit messages, here:

  https://sourceware.org/ml/gdb-patches/2014-01/msg00578.html

This sounds like an interesting idea, but we really would have to
standardize on a particular format, and I think #1 (path and author-
date headers) is the only option that could realistically work.
If we standardize on this now (and put some checks on the server to
weed out bad messages) then come December we'll have four months of
commit messages we can use to check whether we can correctly replicate
the ChangeLog files.  And, if we can, we can consider omitting the
files from the repo and generating them as needed for tarballs.

How does this sound?

Cheers,
Gary

--
http://gbenson.net/