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

["Carlos O'Donell" <carlos at redhat dot com>]

On 08/04/2015 08:38 PM, Siddhesh Poyarekar wrote:
> On Tue, Aug 04, 2015 at 07:50:41PM -0400, Carlos O'Donell wrote:
>> It is easier to keep the act of fixing the bug tightly coupled with
>> marking the bug as fixed since one is more likely to remember to do
>> both at the same time. I estimate the accuracy drops off if you have
>> to open a browser, open bugzilla, open the bug, and mark it fixed.
>>
>> Thus canonically everything lives in source control. The information
>> required to generate a ChangeLog, the information required for the
>> NEWS entry, the information required for the bug to be closed,
> 
> I agree with this, but I also wanted to point out that the Red Hat
> bugzilla has a "Fixed In Version:" field that does what Martin is
> suggesting.  Since marking a bug as closed is something that needs to
> be done manually, setting the "Fixed In Version:" field at that point
> seems like a reasonable thing to expect from maintainers.
> 
> Of course, it is much easier to just trawl the commit logs for the bug
> number since we're already setting that information.

Ideally I'd like to see everything driven by git notes / git commit log
with a dead simple naive automation to generate ChangeLog and 
NEWS, with git notes amendments (as opposed to actually ammending
git history).

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

* NEWS text entries driven by:

	--- NEWS ---
	* Blah blah blah. News entry.
	---

* ChangeLog text entries driven by:

	--- ChangeLog ---
	2015-08-04  Carlos O'Donell  <carlos@redhat.com>
	
		* elf/rtld.c: Rewrite.
	---

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?

Cheers,
Carlos.