This is the mail archive of the
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:51:49 -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>
On 08/04/2015 07:50 PM, Carlos O'Donell wrote:
> 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
> 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,
... and any other information.