Code freeze for glibc-2.19
Joseph S. Myers
joseph@codesourcery.com
Wed Jan 1 14:24:00 GMT 2014
On Wed, 1 Jan 2014, Allan McRae wrote:
> I do not see any other outstanding issues so code freeze is in effect
> now with the usual rules.
I take it you'll deal with regenerating libc.pot and sending a snapshot to
the Translation Project?
> Architecture maintainers: do your thing and report status on the wiki [1].
Note that this should include truncating libm-test-ulps and regenerating
it from scratch (making sure not to add any excessively large ulps, or
ulps for functions such as sqrt and fma that shouldn't have any except
maybe for IBM long double), so as to remove old ulps for tests whose names
have changed or for which the expected ulps have gone down.
Architecture and distribution maintainers: note that the desired state is
no test failures beyond those that the makefiles consider expected to fail
(i.e. those for which plain "make check" without -k would not terminate).
If you observe failures, please investigate them, file bugs in Bugzilla as
necessary and if not fixing them for 2.19 then document them on the wiki
page similarly to previous release documentation such as
<https://sourceware.org/glibc/wiki/Release/2.18>. If as a distributor you
have distribution-local lists of expected failures that include failures
not on the glibc wiki lists, it's a good idea to investigate those further
and see if the testing in preparation for glibc releases needs to include
additional configuration variants to cover the environments in which you
see such failures; it's not a good idea to keep such failures listed
locally without a reason they are inapplicable to mainline glibc.
--
Joseph S. Myers
joseph@codesourcery.com
More information about the Libc-alpha
mailing list