Re: riscv: fmax/fmin sNaN fix

[Joseph Myers <joseph at codesourcery dot com>]

On Thu, 22 Feb 2018, DJ Delorie wrote:

> "Carlos O'Donell" <carlos@redhat.com> 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 
installed glibc.)

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 
scripts/list-fixed-bugs.py.

> (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
joseph@codesourcery.com