Re: glibc 2.23 --- Hard freeze starting

["Carlos O'Donell" <carlos at redhat dot com>]

On 01/20/2016 07:51 AM, Adhemerval Zanella wrote:
> 
> 
> 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.

Agreed.

> 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.

Agreed. I'm worried about this fix from a technical perspective, mostly
because we don't yet have a complete solution. It also isn't clear that
a partial solution is any better than what we have not. I've asked Torvald
if he has a few spare cycles to review.
 
> 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.

I am also inclined to accept such changes.

Cheers,
Carlos.