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

[Joseph Myers <joseph at codesourcery dot com>]

On Wed, 5 Aug 2015, Siddhesh Poyarekar wrote:

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

No, only that the commit message format and tools should be developed and 
adopted together - a stricter format is only justified by having the tools 
that use it, and the tools are the best way of telling whether oddities in 
a particular commit message are actually problematic and need an 
after-the-fact fix-up.

> 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

Will you take responsibility for watching commit messages for each commit 
on master and pointing out to people where they get things wrong and doing 
the fix-ups needed for such mistakes?  (I expect lots of fix-ups to be 
needed at first, fewer later.)

> 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

I don't see the point in a [committed] message if only the log message has 
changed.

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

In what circumstances would this be needed?

If there are actual *conflicts* applying the patch to current master, then 
yes, asking for an updated patch makes sense.  But if the patch was simply 
generated against different versions of the modified files, but still 
applies cleanly to the current versions of those files (possibly at 
different line numbers, possibly with some fuzz), then I think no such 
resubmission should be needed, and if you have automation to detect that a 
patch was committed and mark the patchwork entry as such, that automation 
ought to detect such cases as still being the same patch (even if the log 
message also changed).

-- 
Joseph S. Myers
joseph@codesourcery.com