This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: v2: The GNU C Library 2.16 release plan
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Carlos O'Donell <carlos_odonell at mentor dot com>
- Cc: libc-alpha <libc-alpha at sourceware dot org>, Andreas Jaegar <aj at suse dot com>, Paul Eggert <eggert at cs dot ucla dot edu>, "Ryan S. Arnold" <ryan dot arnold at gmail dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>
- Date: Thu, 31 May 2012 00:13:31 +0000 (UTC)
- Subject: Re: v2: The GNU C Library 2.16 release plan
- References: <4FAC3FCE.1020402@mentor.com>
On Thu, 10 May 2012, Carlos O'Donell wrote:
> * Development freeze of trunk on Monday June 4th.
>
> * Last day of active development is Sunday June 3rd.
>
> * [3 weeks] Ask all machine maintainers to test and report back the
> status of their machines.
>
> * Updating ABI files so ABI check passes.
>
> * Updating ULPs for the release.
>
> * Regenerating any machine files that are out of date.
>
> If I hear back from the machine maintainers quickly then this might be
> as short as 1-2 days and we release early.
I don't think 1-2 days is sensibly practical here.
- The freeze is meant to allow time for ports maintainers to bring sysdeps
files up to date with libc changes. There have been a lot of libc changes
lately requiring corresponding ports changes, many of which (e.g. some
INTDEF/INTUSE changes) have not been called out by their submitters has
involving such port changes. I've been spending most of today simply
keeping ARM, MIPS and powerpc-nofpu up to date with the changes as they go
into libc today. I'm sure you have a rather bigger accumulation of hppa
changes to make....
- It's quite likely testing shows up problems that need investigation and
fixing rather than everything being as clean as one might hope. My
initial attempt at updating MIPS ULPs ran into what looks like a
miscompilation of ilogbl with current trunk GCC, I'm now retrying with GCC
4.7 branch.
- Some people have multiple ports or port variants to test and resolve
problems with. I have four ARM ABIs (big and little endian, hard and soft
float ABIs - though I'm not sure about finding any suitable physical or
virtual system for testing the hard-float ABI, big-endian combination, so
that may just be limited QEMU userspace emulation testing), twelve MIPS
ABIs (big and little endian, hard and soft float, o32, n32 and n64) and
powerpc-nofpu to validate.
Three weeks seems a more practical time for architecture maintainers in
libc and ports to ensure their architectures are up to date and have good
test results not indicating architecture-specific problems. Here freeze
needs to be understood in terms of avoiding any patches likely to need
per-architecture updates (even if those updates are mechanical) or
involving risk of per-architecture breakage more than avoiding changes in
other areas of glibc.
--
Joseph S. Myers
joseph@codesourcery.com