This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Hash out a solution for ChangeLog/NEWS at the Cauldron?
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: Martin Sebor <msebor at gmail dot com>, libc-alpha at sourceware dot org, roland at hack dot frob dot com, joseph at codesourcery dot com
- Date: Tue, 04 Aug 2015 20:56:00 -0400
- Subject: Re: Hash out a solution for ChangeLog/NEWS at the Cauldron?
- Authentication-results: sourceware.org; auth=none
- References: <20150804173912 dot GC2504 at spoyarek dot pnq dot redhat dot com> <55C10308 dot 2050501 at gmail dot com> <55C14FD1 dot 8030105 at redhat dot com> <20150805003840 dot GG2504 at spoyarek dot pnq dot 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.