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

[Siddhesh Poyarekar <siddhesh at redhat dot com>]

On Tue, Aug 04, 2015 at 08:56:00PM -0400, Carlos O'Donell wrote:
> * NEWS bug entry driven by "Resolves: #XXXX, #XXXX, #XXX" bug lines in
>   commit log, with "Related: #XXXX" when not closing the bug but indicating
>   you are fixing part of it.
> 
> 	* Resolves lines include the git commit message and close the bug.
> 	* Related lines just include the git commit message in the bug.

Agreed.

> * NEWS text entries driven by:
> 
> 	--- NEWS ---
> 	* Blah blah blah. News entry.
> 	---

I like Joseph's idea of maintaining it in the NEWS file because it is
much less likely to cause conflicts.

> Then you don't touch NEWS, or ChangeLog ever.
> 
> If you want an updated ChnageLog you run:
> 
> ./update-changelog.sh
> 
> Which notes where you last were when you updated, and processes
> all notes up to the top of the branch.
> 
> Then if you find a defect in the ChangeLog you modify the note,
> regenerate, and then you're done (needs to track all the notes
> that went into the ChangeLog and the regenerate).
> 
> So the git-am workflow includes writing the above into your email
> so that it can get pulled into the patch.
> 
> Is this simply too ugly?

The only problem I see in using git-notes is how the workflow would
look.  The way I see it:

1. Submitter posts patch which includes the ChangeLog in the commit log
2. Reviewer git-am's patch and adds the ChangeLog as a note

The trouble here is that the ChangeLog entry will show up twice in the
git-log output, once as part of the commit log and again as a
git-note.  That is the ugly bit IMO, nothing else.  Editing the
ChangeLog file later is easier, but that has its own workflow issues
now that I think of it.  When do we make such an edit?  If it is an
every commit, then we're essentially doing two or more commits for
every change, one for the actual change and one or more to commit the
generated ChangeLog and for edits to the ChangeLog entry.

Siddhesh