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: Martin Sebor <msebor at gmail dot com>
- To: Carlos O'Donell <carlos at redhat 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 21:48:08 -0600
- 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> <55C15015 dot 8090502 at redhat dot com>
On 08/04/2015 05:51 PM, Carlos O'Donell wrote:
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.
If the commit message can also be made to trigger the Bugzilla
update, it sounds perfect.
FWIW, thanks to Google, most glibc users looking to find out
what bugs have been fixed (or against what release a bug has
been raised) end up either in Bugzilla or on libc-alpha (google
any bug title).
Unfortunately, few glibc bugs in Bugzilla set the "Fixed In
Version" (AKA Target Milestone) field today and so make it
difficult to figure out what release any given bug was fixed
in. The NEWS file has this detail but it doesn't show up in
Google searches, few users know about it, and doesn't have
any of the other relevant information about the bug that
users need (so even if they do find it, they ultimately end
up in Bugzilla anyway).
If an effort is to be made to develop automation to help us
avoid duplicating information in multiple places, it would be
great if it also made it easier for users to find the same
information in one place.