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

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

[Carlos O'Donell]

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.

-- 
Cheers,
Carlos.

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

[Carlos O'Donell]

On 08/01/2016 11:22 AM, 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.

I see I missed the fact that:

* malloc: Remove malloc_get_state, malloc_set_state

Remains on the blocker list.

I think this needs to be deferred to 2.25 at the open of the branch.

The primary reason here is that we should be changing ABI in the freeze.

If you agree, is there anything else blocking 2.24 being cut today?

-- 
Cheers,
Carlos.

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

[Florian Weimer]

On 08/01/2016 05:37 PM, Carlos O'Donell wrote:
> On 08/01/2016 11:22 AM, 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.
>
> I see I missed the fact that:
>
> * malloc: Remove malloc_get_state, malloc_set_state
>
> Remains on the blocker list.
>
> I think this needs to be deferred to 2.25 at the open of the branch.

Yes, I don't expect this to go in at this point.

Thanks,
Florian

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

[Adhemerval Zanella]

On 01/08/2016 12:37, Carlos O'Donell wrote:
> On 08/01/2016 11:22 AM, 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.
> 
> I see I missed the fact that:
> 
> * malloc: Remove malloc_get_state, malloc_set_state
> 
> Remains on the blocker list.
> 
> I think this needs to be deferred to 2.25 at the open of the branch.
> 
> The primary reason here is that we should be changing ABI in the freeze.
> 
> If you agree, is there anything else blocking 2.24 being cut today?
> 

I was about to ask Florian to move it to 2.25, so this only missing
blocked is 'Revised^2: deprecate major/minor/makedev in sys/types.h'
[1] which I created a branch [2] so Zack could check if everything was
ok.  He just resent the changes [3] last Friday, so we need to decide
if the changes should go or not. 

I am in favor to add them, since there are already reviewed (Paul 
Eggert has raised some questioning about first patch, but Zack's
response seem good enough).

[1] https://sourceware.org/ml/libc-alpha/2016-05/msg00274.html
[2] https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/azanella/deprecate-makedev
[3] https://sourceware.org/ml/libc-alpha/2016-07/msg00674.html

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

[Adhemerval Zanella]

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. 

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

[Adhemerval Zanella]

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/

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

[Carlos O'Donell]

On 08/01/2016 02:19 PM, Adhemerval Zanella wrote:
> On 01/08/2016 12:37, Carlos O'Donell wrote:
>> If you agree, is there anything else blocking 2.24 being cut today?
>>
> 
> I was about to ask Florian to move it to 2.25, so this only missing
> blocked is 'Revised^2: deprecate major/minor/makedev in sys/types.h'
> [1] which I created a branch [2] so Zack could check if everything was
> ok.  He just resent the changes [3] last Friday, so we need to decide
> if the changes should go or not. 
> 
> I am in favor to add them, since there are already reviewed (Paul 
> Eggert has raised some questioning about first patch, but Zack's
> response seem good enough).
> 
> [1] https://sourceware.org/ml/libc-alpha/2016-05/msg00274.html
> [2] https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/azanella/deprecate-makedev
> [3] https://sourceware.org/ml/libc-alpha/2016-07/msg00674.html
 
I have followed up on that thread.

My suggestion is to cut 2.24, and then commit Zack's changes to 2.25.

We should cut 2.24 branch on time.

-- 
Cheers,
Carlos.

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

[Adhemerval Zanella]

On 01/08/2016 17:39, Carlos O'Donell wrote:
> On 08/01/2016 02:19 PM, Adhemerval Zanella wrote:
>> On 01/08/2016 12:37, Carlos O'Donell wrote:
>>> If you agree, is there anything else blocking 2.24 being cut today?
>>>
>>
>> I was about to ask Florian to move it to 2.25, so this only missing
>> blocked is 'Revised^2: deprecate major/minor/makedev in sys/types.h'
>> [1] which I created a branch [2] so Zack could check if everything was
>> ok.  He just resent the changes [3] last Friday, so we need to decide
>> if the changes should go or not. 
>>
>> I am in favor to add them, since there are already reviewed (Paul 
>> Eggert has raised some questioning about first patch, but Zack's
>> response seem good enough).
>>
>> [1] https://sourceware.org/ml/libc-alpha/2016-05/msg00274.html
>> [2] https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/azanella/deprecate-makedev
>> [3] https://sourceware.org/ml/libc-alpha/2016-07/msg00674.html
>  
> I have followed up on that thread.
> 
> My suggestion is to cut 2.24, and then commit Zack's changes to 2.25.
> 
> We should cut 2.24 branch on time.
> 

Alright, let's defer to 2.25.  Carlos, as we agree on IRC you can proceed on creating
the 2.24 branch.

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

[Adhemerval Zanella]

On 01/08/2016 17:39, Carlos O'Donell wrote:
> On 08/01/2016 02:19 PM, Adhemerval Zanella wrote:
>> On 01/08/2016 12:37, Carlos O'Donell wrote:
>>> If you agree, is there anything else blocking 2.24 being cut today?
>>>
>>
>> I was about to ask Florian to move it to 2.25, so this only missing
>> blocked is 'Revised^2: deprecate major/minor/makedev in sys/types.h'
>> [1] which I created a branch [2] so Zack could check if everything was
>> ok.  He just resent the changes [3] last Friday, so we need to decide
>> if the changes should go or not. 
>>
>> I am in favor to add them, since there are already reviewed (Paul 
>> Eggert has raised some questioning about first patch, but Zack's
>> response seem good enough).
>>
>> [1] https://sourceware.org/ml/libc-alpha/2016-05/msg00274.html
>> [2] https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/azanella/deprecate-makedev
>> [3] https://sourceware.org/ml/libc-alpha/2016-07/msg00674.html
>  
> I have followed up on that thread.
> 
> My suggestion is to cut 2.24, and then commit Zack's changes to 2.25.
> 
> We should cut 2.24 branch on time.
> 

Alright, let's defer to 2.25.  Carlos, as we agree on IRC you may proceed on creating
the 2.24 branch.

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

[Paul Eggert]

Carlos O'Donell wrote:
> Given all of that it seems to me like we are in a very supportive position
> for Emacs

Yes, I think we're good to go, from the Emacs side.

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

[Carlos O'Donell]

On 08/01/2016 05:39 PM, Paul Eggert wrote:
> Carlos O'Donell wrote:
>> Given all of that it seems to me like we are in a very supportive position
>> for Emacs
> 
> Yes, I think we're good to go, from the Emacs side.

Paul,

Thanks for echoing those comments. I appreciate your input here.

Cheers,
Carlos.