Re: glibc 2.24 -- Cutting the branch and my FSF steward position on __malloc_initialize_hook.

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

On 01/08/2016 15:23, Adhemerval Zanella wrote:
> 
> 
> On 01/08/2016 12:22, Carlos O'Donell wrote:
>> Adhemerval,
>>
>> As an FSF steward my position is that we should _not_ revert the 
>> __malloc_initialize_hook changes, and that we should cut the branch today.
>>
>> My reasons are as follows:
>>
>> * Late ABI changes should not be happening since it may have consequence
>>   on validation and verification.
>>
>> * Patches tested by Sinny Kumari (Red Hat) have shown that Emacs 24 can be
>>   fixed to work pre-dump and post-dump. This means that distributions can
>>   pickup these patches for Emacs 24. We expect Emacs 25 to have these changes
>>   (ff3fc21e24edffccce0d42065833e852a6792bd2 remains).
>>
>> * Red Hat through Fedora is working collaboratively with the Fedora Emacs
>>   maintainers to provide wide-spread testing of the internal allocator in Emacs
>>   through the Fedora 25 release. Other distributions and the community will
>>   benefit from this testing.
>>
>> * It is the responsibility of glibc to work with the community regarding the
>>   deprecation of interfaces. I believe the community has expressed sufficient
>>   notice for the removal of implementation-namespace symbols. The removal is
>>   not taken lightly and the purpose is to further beneficial performance and
>>   security changes in glibc's malloc, changes which impact _all_ of the GNU
>>   ecosystem, not just Emacs.
>>
>> Given all of that it seems to me like we are in a very supportive position
>> for Emacs. We have downstream distro patches ready to make Emacs 24 work.
>> We have test and support infrastructure to run Emacs in F25 with their own
>> internal allocator. And Emacs 25 will function correctly. I don't see
>> that there is a better time to deprecate the symbols, and I don't see
>> another 6 months buying us any further value.
>>
>> My only concerns would be if a distribution choose not to adopt a new glibc
>> version because of the Emacs breakage. This would mean the distribution
>> misses out on all the fixes in the new glibc version. I expect this to be
>> mitigated by the Emacs patches and testing being done by the major upstream
>> distributions.
>>
> 
> I think you summarized all the relevant points and showed we as the GLIBC
> community are providing not enough time for Emacs adjustments, but some
> infrastructure as well.  I already expressed my point in favor of not 
> reverting the change, so I think we can move out this issue out of the
> release blockers. 
> 

s/not enough time/not just enough/