Re: Hash out a solution for ChangeLog/NEWS at the Cauldron?

[Joseph Myers <joseph at codesourcery dot com>]

On Tue, 4 Aug 2015, Siddhesh Poyarekar wrote:

> I don't know how many of us are going to be at the Cauldron this

I won't be at the Cauldron.

> patches?  We're at an almost perfect position with development frozen
> (we could keep it frozen for a week till we sort this out so that we

I don't think we should keep development frozen for such a purpose.  If we 
develop new tools that are most conveniently used from the start of a 
release cycle (and I don't see why tools should depend on when you start 
using them), then start using them after 2.23.  I expect a significant 
amount of work would be needed to develop appropriate tools, rework the 
process for building releases etc. and make sure that the tools don't lose 
flexibility; a week is hardly realistic.

> What I'm thinking of is a policy that'll allow us to auto-generate
> ChangeLog and NEWS from commit data so that whatever is posted on the
> list can be git-am'd directly and merged into master without rewriting
> the commit.  This will allow for tighter integration with patchwork,

I think it's very unlikely casual contributors will get the formatting 
details right (and for contributors with write access, being able to 
git-am is irrelevant in many cases because either the patch is committed 
before sending or changes at least to the commit message are likely before 
commit).

> Acked-by too).  The ChangeLog entry can be identified with a
> ChangeLog: tag.  Likewise, we could have a NEWS: tag to identify NEWS
> items for the release and a BUGS: tag to include bugs that this commit
> resolves.

I think normal NEWS items for significant changes (as opposed to the list 
of fixed bugs) are most appropriately handled through the 
version-controlled text file rather than special processing of commit logs 
(and the patch to NEWS should be included in the patch proposing such a 
significant change, but if not included, can always go in a later patch).  
This allows for easy editing, reordering etc. - while any system for 
automatic processing of commit logs needs to allow for arbitrary mistakes 
in those logs to be corrected when generating ChangeLogs and lists of 
fixed bugs, it's inevitably more cumbersome than simply editing the NEWS 
file directly.

> With this in place, the patch committer should take care to never
> rebase the patch into master and instead 'merge' it in to preserve
> history.  Alternatively, (s)he could ask the submitter to rebase and
> provide a patch.

I don't understand what's suggested here.  I don't find merge commits on 
master useful for normal changes (and if you generate the ChangeLog 
entries automatically from commit messages, and the list of fixed bugs 
either from those or from Bugzilla, then actual merge conflicts should be 
rare) - I prefer the linear history.  (There might be exceptional cases of 
development branches where merge commits are helpful, but not for normal 
small incremental glibc patches.)

I would be happy to eliminate use of the separate libidn/ChangeLog and 
localedata/ChangeLog to simplify ChangeLog generation (or indeed even 
without automatic ChangeLog generation).

-- 
Joseph S. Myers
joseph@codesourcery.com