This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Code freeze for glibc-2.19
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Allan McRae <allan at archlinux dot org>
- Cc: libc-alpha <libc-alpha at sourceware dot org>
- Date: Wed, 1 Jan 2014 14:24:09 +0000
- Subject: Re: Code freeze for glibc-2.19
- Authentication-results: sourceware.org; auth=none
- References: <52C40F69 dot 9050604 at archlinux dot org>
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