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