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

[Martin Sebor <msebor at gmail 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
> > > 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,
>
> ... 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.

Martin