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

[Joseph Myers <joseph@codesourcery.com>]

On Sun, 1 Jan 2017, Florian Weimer wrote:

> On 01/01/2017 01:27 AM, Joseph Myers wrote:
> > I've updated copyright dates in glibc for 2017.  This is the patch for
> > the changes not generated by scripts/update-copyrights and subsequent
> > build / regeneration of generated files.
> 
> Could we rotate the ChangeLog file, too, please?

ChangeLog rotation was previously objected to in 
<https://sourceware.org/ml/libc-alpha/2013-06/msg00305.html>.

What I think we should now aim for regarding ChangeLogs - not during a 
freeze apart maybe from the first step - is:

1. Move libidn/ChangeLog to ChangeLog.libidn, localedata/ChangeLog to 
ChangeLog.localedata, stop using separate ChangeLogs for those 
subdirectories and just put everything in the toplevel ChangeLog.

2. Develop conventions for embedding ChangeLog entries in git commit 
messages to support automatic ChangeLog generation.  Develop a script to 
be run from the pre-receive hook that rejects master and release branch 
updates unless they have a properly formatted ChangeLog entry following 
those conventions in their commit messages for each pushed commit (or 
follow appropriate conventions for indicating a commit that deliberately 
does not have a ChangeLog entry).  Develop a script that updates ChangeLog 
with the messages for all commits since that script was last run.

3. Declare a flag day, at which ChangeLog is renamed to ChangeLog.18 and 
future commits do not add entries to ChangeLog except as a result of 
running that script.

4. As the last commit before a release is tagged, the script would be run 
to update ChangeLog and the results committed, so that releases can 
continue to be built with "git archive".  In addition, if a mistake or 
omission in a ChangeLog entry in a past commit message is to be corrected, 
the approach would be to run the script, commit the results, then edit the 
resulting ChangeLog content; this avoids the need for any on-the-side list 
of edits to ChangeLog entries.

Not needing to be done as part of the move to automatically generated 
ChangeLogs, but facilitated by it, would be arranging for patchwork to 
automatically mark patches committed when the git-patch-id of a commit is 
the same as that of a patch in patchwork (because it would become normal 
for a patch posted for review to be the same as the patch that gets 
committed).  This would reduce the extent to which patchwork fills up with 
patches that have in fact been committed, although manual work is still 
needed to deal with the backlog (both reviewing patches that need review, 
and updating entries for patches that have in fact been committed or 
superseded).

-- 
Joseph S. Myers
joseph@codesourcery.com