Re: Updating NEWS for 2.26

[Joseph Myers <joseph at codesourcery dot com>]

On Wed, 5 Jul 2017, Zack Weinberg wrote:

> On Tue, Jul 4, 2017 at 10:40 AM, Carlos O'Donell <carlos@redhat.com> wrote:
> > On 07/04/2017 10:36 AM, Zack Weinberg wrote:
> >>
> >> Given the variety of changes in this release I think some more
> >> organization of NEWS would be helpful, as well.  I'm thinking
> >> subsections for changes to build requirements, new features,
> >> deprecated and/or removed features, important bugfixes.
> >
> > Sure, I'll see what kind of logical groups the changes fall into.
> >
> > If you have a change in mind, please just checkin rough text and I'll
> > wordsmith it later.
> 
> This is done now; please feel free to make further changes as you see fit.

Should we use those subject headings as standard for future releases?  So, 
change the template for the NEWS section for a new release cycle at 
<https://sourceware.org/glibc/wiki/Release> to include all those headings, 
on the basis that if a particular release doesn't have anything under one 
of the headings, we'll remove that section during the freeze.

> I am wondering whether we really need a comprehensive list of all the
> TS 18661-3 macros and functions.  It's a giant wall of text and it may
> make people think they're done reading, when the very important
> "deprecated and removed features" section is just below.

We should indicate in some way what the features are, at least, even 
without a full list.  That is, a minimum is to indicate the general naming 
patterns (cf. the GCC 7 release notes, where I didn't try to give a full 
list of every possible macro or built-in function for these types, just to 
indicate the patterns); that they apply to all non-obsolescent interfaces 
that we have for long double, whether standard or not; that the support 
does not include those TS 18661-3 interfaces that aren't float128 versions 
of interfaces for other types.  (We may not want to say specifically what 
exactly counts as obsolescent, but maybe note that there is no 
printf/scanf support for the type, with the strfromf128 / strtof128 
functions being expected to be used instead.)  I wonder if we should also 
mention the need for nondefault feature test macros to make these features 
visible, either _GNU_SOURCE or __STDC_WANT_IEC_60559_TYPES_EXT__.

Also: there's a statement "Support for more architectures will be added in 
future releases.".  I intend to enable support for _FloatN/_FloatNx 
functions in future *where they are aliases of functions for existing 
types*, but I'm still wary of making statements in NEWS about features to 
be added in future releases.  I don't think support for float128 
functions, specifically, is that likely to be added on more architectures 
where they aren't aliases for long double (the only glibc architecture 
with long double != float128, no float128 support in glibc, but float128 
support in current GCC, is hppa, where the GCC float128 support exists but 
is for HP-UX only.  (As noted in passing, I can envisage adding _Float16 
support in future, which would be completely new function implementations, 
however.)

I've applied this patch to say "GNU C Library" consistenly in NEWS items 
rather than the shorthand "glibc".

diff --git a/NEWS b/NEWS
index d54a3d6..5fbd0cf 100644
--- a/NEWS
+++ b/NEWS
@@ -19,19 +19,19 @@ Major new features:
 
 * Improvements to the DNS stub resolver, contributed by Florian Weimer:
 
-  - glibc will now detect when /etc/resolv.conf has been modified and reload
-    the changed configuration.  The new resolver option “no-reload”
-    (RES_NORELOAD) disables this behavior.
+  - The GNU C Library will now detect when /etc/resolv.conf has been
+    modified and reload the changed configuration.  The new resolver option
+    “no-reload” (RES_NORELOAD) disables this behavior.
 
-  - glibc now supports an arbitrary number of search domains (configured using
-    the “search” directive in /etc/resolv.conf); previously, there was a
-    hard limit of six domains.  For backward compatibility, applications
-    that directly modify the ‘_res’ global object are still limited to six
-    search domains.
+  - The GNU C Library now supports an arbitrary number of search domains
+    (configured using the “search” directive in /etc/resolv.conf);
+    previously, there was a hard limit of six domains.  For backward
+    compatibility, applications that directly modify the ‘_res’ global
+    object are still limited to six search domains.
 
-  - When the “rotate” (RES_ROTATE) resolver option is active, glibc will now
-    randomly pick a name server from the configuration as a starting point.
-    (Previously, the second name server was always used.)
+  - When the “rotate” (RES_ROTATE) resolver option is active, the GNU C
+    Library will now randomly pick a name server from the configuration as a
+    starting point.  (Previously, the second name server was always used.)
 
 * The tunables feature is now enabled by default.  This allows users to tweak
   behavior of the GNU C Library using the GLIBC_TUNABLES environment variable.
@@ -167,7 +167,7 @@ Deprecated and removed features, and other changes affecting compatibility:
   removed.
 
 * Sun RPC is deprecated.  The rpcgen program, librpcsvc, and Sun RPC headers
-  will only be built and installed when glibc is configured with
+  will only be built and installed when the GNU C Library is configured with
   --enable-obsolete-rpc.  This allows alternative RPC implementations, such
   as TIRPC or rpcsvc-proto, to be used.
 
@@ -178,8 +178,8 @@ Deprecated and removed features, and other changes affecting compatibility:
   The NIS(+) support library, libnsl, is also deprecated.  By default, a
   compatibility shared library will be built and installed, but not headers
   or development libraries. Only a few NIS-related programs require this
-  library.  (In particular, glibc has never required programs that use
-  'gethostbyname' to be linked with libnsl.)
+  library.  (In particular, the GNU C Library has never required programs
+  that use 'gethostbyname' to be linked with libnsl.)
 
   Replacement implementations based on TIRPC, which additionally support
   IPv6, are available from <https://github.com/thkukuk/>.  The configure
@@ -247,15 +247,15 @@ Changes to build and runtime requirements:
   supported by that kernel.  (This is a change from version 2.25 only for
   x86-32 and x86-64.)
 
-* GNU Binutils 2.25 or later is now required to build glibc.
+* GNU Binutils 2.25 or later is now required to build the GNU C Library.
 
-* On most architectures, GCC 4.9 or later is required to build glibc.  On
-  powerpc64le, GCC 6.2 or later is required.
+* On most architectures, GCC 4.9 or later is required to build the GNU C
+  Library.  On powerpc64le, GCC 6.2 or later is required.
 
   Older GCC versions and non-GNU compilers are still supported when
-  compiling programs that use glibc.  (We do not know exactly how old,
-  and some GNU extensions to C may be _de facto_ required.  If you are
-  interested in helping us make this statement less vague, please
+  compiling programs that use the GNU C Library.  (We do not know exactly
+  how old, and some GNU extensions to C may be _de facto_ required.  If you
+  are interested in helping us make this statement less vague, please
   contact libc-alpha@sourceware.org.)
 
 Security related changes:

-- 
Joseph S. Myers
joseph@codesourcery.com