This is the mail archive of the
mailing list for the glibc project.
Re: riscv: fmax/fmin sNaN fix
- From: Joseph Myers <joseph at codesourcery dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, <libc-alpha at sourceware dot org>
- Date: Thu, 22 Feb 2018 20:42:40 +0000
- Subject: Re: riscv: fmax/fmin sNaN fix
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com>
On Thu, 22 Feb 2018, DJ Delorie wrote:
> "Carlos O'Donell" <firstname.lastname@example.org> writes:
> > If there is a release out for RISC-V alrady, then this needs a bug number.
> If that's the rule, then *every* change needs a bug number, because
> there's always a "release out" for some platform...
It's for changes that fix a bug that was user-visible in a release. (My
interpretation of being user-visible in a release excludes bugs that
caused the build to be broken, or bugs in the manual, or bugs in a
testcase, or test failures such as check-localplt where a failure only
indicates an optimization issue rather than an actual misbehavior in the
New features and internal cleanups never need bugs filed in Bugzilla;
likewise fixes for issues introduced on master after the last release, and
for bugs in new features added since the last release.
We want the NEWS file to be as complete as possible regarding user-visible
changes. For new features and significant optimizations, entries are
added to the relevant section of the NEWS file by hand (and should be
included in the patches adding such features). For miscellaneous
bugfixes, the only reference in NEWS may be in the automatically-generated
list of fixed bugs. For that list to be as complete as possible, a bug
needs filing in Bugzilla before being fixed, then marking as FIXED with
target milestone set to the next release once the fix is checked in; that
way, it will be automatically included in the list generated by
> (distinct from "backports to release branches need a bug number, for
> tracking", if that's a rule)
We don't have such a rule. Backports to release branches should be posted
to the libc-stable list.
Joseph S. Myers