Re: glibc 2.23 --- Hard freeze starting

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 19-01-2016 20:31, Mike Frysinger wrote:
> On 19 Jan 2016 21:50, Joseph Myers wrote:
>> On Tue, 19 Jan 2016, Adhemerval Zanella wrote:
>>> My understanding is we set a long freeze period (usually a month) to exact
>>> iron out these kind of discussions.  The freeze is exactly to limit discussion
>>> to a limited number of topics to avoid backlog overflow.
>>
>> I think the freeze is to allow plenty of time for architecture maintainers 
>> to test for their architectures and fix problems found (so that it 
>> shouldn't, for example, be a problem if some architecture maintainers are 
>> away at the start of the freeze period) - and potentially for any extra 
>> testing people wish to run while changes likely to invalidate it shouldn't 
>> be going in.  Not for adding new architecture-independent ABIs or other 
>> changes that strongly indicate architecture maintainers should revalidate 
>> (any new ABI means architecture maintainers should at least confirm the 
>> ABI tests still pass).
> 
> agreed.  while it's annoying when your patchset missed another window, i
> don't think we should be allowing any changes like this w/out a very good
> reason.  freezes are for stabilizing/testing/validating, not for slipping
> your pet projects in at the last minute (this is a generalization and is
> not directed at anyone in particular -- i'd point out that i have one or
> two patches that i wish would have made this release).
> 
> it's not like we won't have another release in the future.
> -mike

Right, so then we need to enforce a policy of what is feasible to set as
release blocker and what should be moved to the next one.  As you said,
architecture-independent ABI should not be a blocker, so the patches for
'Fix ABI for external copies of string function inlines on AArch64'
should be delay to 2.24.

So general bugfixes that has no consent/review until hard freeze I am
inclined to delay to next version.  This applies to "[BZ #19329] Fix 
race between tls allocation at thread creation and dlopen", which Carlos
has raised some concerns to apply on 2.23.

Finally we need to set what kind of last minute bugfixes should be allowed
or not.  I noted some testcases fixes because of mantainers started to
tests and check on the failures.  This potentially invalidate some
previous tests from other architectures, however they are still required
due the flawed test itself.  I am usually inclined to accept such changes.