This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Using the vcs_to_changelog.py script


> Cc: binutils@sourceware.org, gdb-patches@sourceware.org
> From: Simon Marchi <simon.marchi@polymtl.ca>
> Date: Thu, 13 Feb 2020 11:26:11 -0500
> 
> My understanding from:
> 
>   - past dicussions (the big one on bug-
>   - the proposed change to standards.texi that you sent
> 
> is that the ChangeLog entry is redundant enough with the combination of:
> 
>   - a good commit message that explains why the change is done
>   - the diff of the change
> 
> which are both kept by the VCS.  And for that reason, it's fine not to keep
> a ChangeLog file in the VCS.

Yes, but:

  1) the proposed change was not yet approved as part of the official
     policy

  2) we need some guidelines for "good commit messages", otherwise
     patch review will need to pay a lot of attention to discussing
     that and making sure the log messages are fine

> However, for the benefit of people just using
> tarballs, and not the VCS, we generate a ChangeLog file from the diff.
> Naturally, the generated ChangeLog will be less informative than one written
> by humans (it won't say what changed in a function, it will just say that
> the function has been modified), but since that procedure was adopted by glibc,
> and is mentioned in the proposed standards.texi change, then it must have been
> considered an acceptable compromise.

I have yet to see this accepted as GNU policy.  And at least
personally, having a ChangeLog in a tarball that just says which
function was changed on what date is almost useless to me (and I do
sometimes need to work without access to the VCS repositories).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]