Re: Update copyright dates not handled by scripts/update-copyrights [committed]

[Joseph Myers <joseph@codesourcery.com>]

On Mon, 2 Jan 2017, Torvald Riegel wrote:

> > The newer logs are a matter of the GNU Coding Standards.  That is, if you 
> > don't want to maintain information about "what" changed in that particular 
> > form, you should be persuading the GCS maintainers to allow just logging 
> > descriptions of what and why changed at the logical level rather than the 
> > level of individual files and functions (in the case where a version 
> > control system provides tracking of the "what" ... not all GNU packages 
> > have public version control).
> 
> Are you saying that from your point of view, GCS is the only significant
> reason for maintaining changelogs?

My suggestion is that it would be reasonable to argue to the GCS 
maintainers that ChangeLog-format logs need not be maintained for a 
package for which all of the following are true:

* it has public version control,

* in a distributed VCS,

* where commits are made for each logical change, not batched into a 
commit per release (see bash for an example of such batching) or per day 
or other such batching,

* with authors not just committers tracked,

* with commit messages describing the logical "what" changed (but not 
describing the physical "what" at the level of changes to individual files 
and functions).

That is, when all the above are true, the information about changes is 
more usefully available through the VCS than through ChangeLog-style 
messages and people wanting that information will be expecting to go to 
the VCS for it rather than to find it in the release tarballs, so 
ChangeLog-style messages can be considered obsoleted by the VCS in that 
case (and in that case, the GCS requirements for ChangeLog files do not 
serve a useful technical purpose - this is a separate matter from any 
legal reasons there might be for including such information about changes 
and their authorship in release tarballs).

> Maybe we should just announce that we'll stop doing changelogs and see
> whether anybody complains.  If people complain, it would be interesting

That's not an appropriate way to work for a GNU package.  We need to work 
with the GNU project (and quite possibly, the FSF in turn work with their 
lawyers to establish if there are any legal reasons relating to 
attribution of changes within releases).

If the GCS were then changed along the lines I propose above, we'd still 
need to establish appropriate conventions for commit message contents - 
that is, that any nontrivial change should include a description in the 
commit message along the lines of what goes in the mailing list posting of 
the patch.  But we can of course establish such a rule for meaningful 
commit messages independently of a change to the GCS.

-- 
Joseph S. Myers
joseph@codesourcery.com