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

[Siddhesh Poyarekar <siddhesh at redhat dot com>]

On Tue, Aug 04, 2015 at 05:59:27PM +0000, Joseph Myers wrote:
> 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.

Tools development before we adopt the new workflow implies that we
keep the generated ChangeLog and NEWS files updated with each commit;
I did not imply that.  They need to be ready by the time the next
release happens and that I can take responsibility for.  So the week
is to just finalize the workflow.  I don't have a strong opinion about
extending the freeze though.  If we decide that 2.23 cannot have this
workflow then fair enough, we can use it as a transition and then
follow it strictly for 2.24.

> 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).

Casual contributors don't get a lot of the current details right
either, but we live with it.  We can figure out a way to adjust for
it; one idea would be for the committer to post a [committed] patch in
such cases.  A bigger worry is someone accidentally pushing a patch
with the incorrect commit message because we cannot rewrite the commit
after that.

> 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.

Yes, that sounds good to me.

> > 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 suggested two options:

1. Committer always applies patch to a temp branch and then merges
   into master.  That way conflicts are recorded

OR

2. Committer asks submitter to resubmit patch such that it applies
   cleanly to master.

glibc is not as fast moving, so option 2 seems better.  I think you
like (2) better as well since it will produce a linear, clean history
without the merge commits.

> 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).

+1, Lets adopt this immediately once 2.23 development opens.

Siddhesh