glibc 2.28 is in slushy freeze.

glibc 2.28 is in slushy freeze.

[Carlos O'Donell]

Community,

We are in slushy freeze.

I'm going to start reviewing the patches for the release blockers.

Please help me in doing so.

If you are not on the list of release blockers and need some kind
of ABI change, please speak up now.

I have already reviewed Maciej's ABSOLUTE changes in this regard
and they are OK for 2.28.

-- 
Cheers,
Carlos.

Re: glibc 2.28 is in slushy freeze.

[H.J. Lu]

On Thu, Jul 5, 2018 at 7:24 AM, Carlos O'Donell <carlos@redhat.com> wrote:
> Community,
>
> We are in slushy freeze.
>
> I'm going to start reviewing the patches for the release blockers.
>
> Please help me in doing so.
>
> If you are not on the list of release blockers and need some kind
> of ABI change, please speak up now.
>
> I have already reviewed Maciej's ABSOLUTE changes in this regard
> and they are OK for 2.28.

I'd like to get CET into 2.28.


-- 
H.J.

Re: glibc 2.28 is in slushy freeze.

[Carlos O'Donell]

On 07/05/2018 10:34 AM, H.J. Lu wrote:
> On Thu, Jul 5, 2018 at 7:24 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>> Community,
>>
>> We are in slushy freeze.
>>
>> I'm going to start reviewing the patches for the release blockers.
>>
>> Please help me in doing so.
>>
>> If you are not on the list of release blockers and need some kind
>> of ABI change, please speak up now.
>>
>> I have already reviewed Maciej's ABSOLUTE changes in this regard
>> and they are OK for 2.28.
> 
> I'd like to get CET into 2.28.

I will review this next.

-- 
Cheers,
Carlos.

Re: glibc 2.28 is in slushy freeze.

[Adhemerval Zanella]

On 05/07/2018 11:24, Carlos O'Donell wrote:
> Community,
> 
> We are in slushy freeze.
> 
> I'm going to start reviewing the patches for the release blockers.
> 
> Please help me in doing so.
> 
> If you are not on the list of release blockers and need some kind
> of ABI change, please speak up now.
> 
> I have already reviewed Maciej's ABSOLUTE changes in this regard
> and they are OK for 2.28.
> 

I added ISO C threads.h to desirable features.  This patchset is
from 02/2018 [1] and it is not updated for branch, however the
adjustments required are only for the abilist files and I have
a updated branch on my personal repo [2].

[1] https://sourceware.org/ml/libc-alpha/2018-02/msg00066.html
[2] https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/azanella/c11-threads

Re: glibc 2.28 is in slushy freeze.

[Albert ARIBAUD]

Hi Carlos,

On Thu, 5 Jul 2018 10:24:52 -0400, Carlos O'Donell <carlos@redhat.com>
wrote :

> Community,
> 
> We are in slushy freeze.
> 
> I'm going to start reviewing the patches for the release blockers.
> 
> Please help me in doing so.
> 
> If you are not on the list of release blockers and need some kind
> of ABI change, please speak up now.
> 
> I have already reviewed Maciej's ABSOLUTE changes in this regard
> and they are OK for 2.28.

Depending on how gnulib syncs on glibc, I /might/ request that at least
the very first patch from the Y2038 series (the one which defines
__time64_t) be pulled in the upcoming glibc release so that I can move
forward with Paul Eggert's request that at least part of the Y2038
glibc patches go through gnulib first.

This patch would have zero impact on existing code as it just adds a
publicly visible type, and therefore presents zero risk of breaking
existing user source or object code.

I'll follow up on this reply as soon as I know whether I do need
to request the patch pull in or not.

Cordialement,
Albert ARIBAUD
3ADEV

Re: glibc 2.28 is in slushy freeze.

[Carlos O'Donell]

On 07/06/2018 06:35 AM, Albert ARIBAUD wrote:
> Hi Carlos,
> 
> On Thu, 5 Jul 2018 10:24:52 -0400, Carlos O'Donell <carlos@redhat.com>
> wrote :
> 
>> Community,
>>
>> We are in slushy freeze.
>>
>> I'm going to start reviewing the patches for the release blockers.
>>
>> Please help me in doing so.
>>
>> If you are not on the list of release blockers and need some kind
>> of ABI change, please speak up now.
>>
>> I have already reviewed Maciej's ABSOLUTE changes in this regard
>> and they are OK for 2.28.
> 
> Depending on how gnulib syncs on glibc, I /might/ request that at least
> the very first patch from the Y2038 series (the one which defines
> __time64_t) be pulled in the upcoming glibc release so that I can move
> forward with Paul Eggert's request that at least part of the Y2038
> glibc patches go through gnulib first.
> 
> This patch would have zero impact on existing code as it just adds a
> publicly visible type, and therefore presents zero risk of breaking
> existing user source or object code.
> 
> I'll follow up on this reply as soon as I know whether I do need
> to request the patch pull in or not.

Sure, that sounds reasonable. You'll have to call this out for review
here:

https://sourceware.org/glibc/wiki/Release/2.28#Planning

Please put it under blockers.

-- 
Cheers,
Carlos.

Re: glibc 2.28 is in slushy freeze.

[Joseph Myers]

On Fri, 6 Jul 2018, Albert ARIBAUD wrote:

> Depending on how gnulib syncs on glibc, I /might/ request that at least
> the very first patch from the Y2038 series (the one which defines
> __time64_t) be pulled in the upcoming glibc release so that I can move
> forward with Paul Eggert's request that at least part of the Y2038
> glibc patches go through gnulib first.

I don't think it makes any sense for this to be a freeze exception.  It's 
not a user-visible feature (it's a type in the implementation namespace) 
so it doesn't matter in the least whether it's present in 2.28 or not, and 
so because it doesn't provide any benefit to the release, it's safest to 
keep it out.

Given there are plenty of design discussions around the proposed 64-bit 
time patches and it seems likely various aspects of the patch design will 
change in future versions, it's a lot better for the first patches to go 
in at the *start* of a release cycle - when there's plenty of time for 
subsequent reworking as designs change in the course of implementation and 
review - than at the end of a release cycle, when you risk, at the very 
least, confusing people who look at the 2.28 release in future with having 
something there that is significantly different from both the final design 
and from previous releases.

-- 
Joseph S. Myers
joseph@codesourcery.com