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: Martin Sebor <msebor at gmail dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>, libc-alpha at sourceware dot org
- Cc: roland at hack dot frob dot com, joseph at codesourcery dot com
- Date: Tue, 04 Aug 2015 19:50:41 -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>
On 08/04/2015 02:23 PM, Martin Sebor wrote:
>> What I'm thinking of is a policy that'll allow us to auto-generate
>> ChangeLog and NEWS from commit data so that whatever is posted on the
>> list can be git-am'd directly and merged into master without rewriting
>> the commit. This will allow for tighter integration with patchwork,
>> to mark committed patches as closed automatically, leaving just
>> superseded patches to clean up.
>
> Would using Bugzilla to keep track of which release each bug was
> fixed in be a appealing solution? It would make it easier to find
> them and generate useful reports for each release. Such reports
> are often helpful when deciding which release to adopt. The NEWS
> file could also be generated from such a report just before each
> release.
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,
c.