This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.24 --- Starting soft/slush freeze discussion
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 4 Jul 2016 10:04:41 -0300
- Subject: Re: glibc 2.24 --- Starting soft/slush freeze discussion
- Authentication-results: sourceware.org; auth=none
- References: <57757DBB.2060404@linaro.org> <5776B9DA.20909@linaro.org> <alpine.DEB.2.20.1607012256371.27720@digraph.polyomino.org.uk>
On 01/07/2016 20:01, Joseph Myers wrote:
> On Fri, 1 Jul 2016, Adhemerval Zanella wrote:
>
>> I have updated the 2.24 release wiki with H.J. Lu, Zach Weinberg and mine
>> updates as blockers and desirables.
>>
>> I added the 3 bugs appointed by H. J. Lu in releases blockers mainly because
>> there are potentially build breakers and important ABI fixes (X86-64: Properly
>> align stack in _dl_tlsdesc_dynamic). I also added Zach's sysmacros as a blocker,
>> although I do not have a strong opinion about them (I am about to read all the
>> thread now). I have also add two releases blocker from my side: 1 .Refactor
>> Linux raise implementation (BZ#15368) and 2. Remove __ASSUME_OFF_DIFF_OFF64 definition.
>>
>> I have added the 'Check GLIBC_IFUNC to enable/disable ifunc features' in desirables
>> features mainly from a conservative approach (it was sent late in release cycle,
>> it is still in review process, it only addresses x86_64). We can move it to
>> release blocker if there are consensus about it.
>
> I don't think GLIBC_IFUNC or tunables are appropriate at this stage -
> anything involving new environment variables requires very careful
> consideration (of what APIs we want to support for users, of possible
> security issues, etc.) that we simply don't have time to do properly now.
> Because of the risk of architecture-specific issues that would invalidate
> testing already underway, [...]
Right, both last iterations were indeed sent in a late stage. I will remove
both form release blockers.
> [...] I don't think the *fallocate* consolidations are
> appropriate now either. [...]
I will remove it also from release blockers.
> I also think the pretty-printers are too big a
> change to include at this point.
>
For pretty-printers I tend to agree with Siddhesh that it has been reviewed
for some time and it does not impact in any primary functionality.