Re: Code freeze for glibc-2.19

["Joseph S. Myers" <joseph at codesourcery dot com>]

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