This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Updating NEWS for fixed bugs
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: libc-alpha at sourceware dot org
- Date: Fri, 17 Feb 2012 00:47:49 +0000 (UTC)
- Subject: Updating NEWS for fixed bugs
Recent practice appears to have been that the lists of fixed bugs in NEWS
get updated by the person committing a fix for a bug, either in the same
commit or shortly afterwards. (This has also applied for bugs in Bugzilla
that requested cleanups or features: anything entered in Bugzilla whether
or not strictly a "bug" in the code.) NEWS changes have not had ChangeLog
entries lately.
I've just updated NEWS for two recent fixes (bugs 4822, 11494); please try
to remember this update (and the [BZ #n] notation in the ChangeLog) when
committing changes. Obviously the list won't be perfect - sometimes bug
entries will be forgotten or it will only be noticed after a release that
a bug has been fixed - but hopefully we can keep it reasonably complete.
(I don't think an approach based on automatic extraction from the
ChangeLogs, or a hypothetical rule for how to indicate in Bugzilla the
version with a fix, would be any more reliable - though arguably a "fixed
in" field in Bugzilla, with a link in the NEWS file to a search, would be
more useful and meaningful than a list of bare numbers. And a fix for a
bug in a release may not have a well-defined "main" commit that fixes it
to identify as such in the ChangeLog. Consider bug 13695 - presumably
fixed by the initfini changes, but it would have been a bit odd to mark
the changes for the last architecture as the ones fixing the bug in the
ChangeLog. Or my bug 411 (__i686) fix - I put the annotation on the
change to sysdep.h that actually involved undefining and redefining
__i686, but the initfini changes were needed to complete that fix. So I
think of [BZ #n] as meaning "this change is related to bug n" rather than
"this change is a complete fix to bug n and bug n should be listed as
fixed in the next release".)
(ports should probably have its own NEWS file, which would record
information about fixed port bugs and other port news in releases.)
--
Joseph S. Myers
joseph@codesourcery.com