Re: v2: The GNU C Library 2.16 release plan

["Joseph S. Myers" <joseph at codesourcery dot 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