2.31: < 2 weeks to go

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

2.31: < 2 weeks to go

Siddhesh Poyarekar-8
Hello folks,

Less than two weeks to go for 2.31 freeze.  I intend to announce a
freeze on 31st December around afternoon IST.  Here's a reminder that if
you'd like your patchset considered for inclusion during the freeze, it
needs to be in the blockers list on the release page[1].  Please cc me
in patch pings if you haven't been able to get reviews and need attention.

Siddhesh

[1] https://sourceware.org/glibc/wiki/Release/2.31
Reply | Threaded
Open this post in threaded view
|

Re: 2.31: < 2 weeks to go

Carlos O'Donell-5
On 12/19/19 10:35 PM, Siddhesh Poyarekar wrote:

> Hello folks,
>
> Less than two weeks to go for 2.31 freeze.  I intend to announce a
> freeze on 31st December around afternoon IST.  Here's a reminder that if
> you'd like your patchset considered for inclusion during the freeze, it
> needs to be in the blockers list on the release page[1].  Please cc me
> in patch pings if you haven't been able to get reviews and need attention.
>
> Siddhesh
>
> [1] https://sourceware.org/glibc/wiki/Release/2.31
>

Arjun,

I think your gconv cleanup should go on this list. We've been reviewing
this code internally and externally and it really helps with the converter
hangs.

I'll look at reviewing this after I get done the Mentor Graphics review
for ld.so sorting.

Chung-Lin,

I suggest you also put the dynamic loader improvements on the blocker
list. I've been look at these for months, and I haven't found anything
really wrong with them. I need to post my review writeup, but I keep
getting blocked. I'm going to do that either tomorrow or next week.

Thanks!

--
Cheers,
Carlos.

Reply | Threaded
Open this post in threaded view
|

Re: 2.31: < 2 weeks to go

Arjun Shankar-2
> On 12/19/19 10:35 PM, Siddhesh Poyarekar wrote:

> > Less than two weeks to go for 2.31 freeze.  I intend to announce a
> > freeze on 31st December around afternoon IST.  Here's a reminder that if
> > you'd like your patchset considered for inclusion during the freeze, it
> > needs to be in the blockers list on the release page[1].  Please cc me
> > in patch pings if you haven't been able to get reviews and need
> > attention.

> > [1] https://sourceware.org/glibc/wiki/Release/2.31

On Thu, 2019-12-19 at 22:56 -0500, Carlos O'Donell wrote:

> Arjun,
>
> I think your gconv cleanup should go on this list. We've been reviewing
> this code internally and externally and it really helps with the converter
> hangs.
>
> I'll look at reviewing this after I get done the Mentor Graphics review
> for ld.so sorting.

I added an entry for the iconv option parsing rewrite to the list of
blockers. I have a v2 coming up, hopefully today.

Cheers,
Arjun

Reply | Threaded
Open this post in threaded view
|

Re: 2.31: < 2 weeks to go

Florian Weimer-5
In reply to this post by Siddhesh Poyarekar-8
* Siddhesh Poyarekar:

> Less than two weeks to go for 2.31 freeze.  I intend to announce a
> freeze on 31st December around afternoon IST.  Here's a reminder that if
> you'd like your patchset considered for inclusion during the freeze, it
> needs to be in the blockers list on the release page[1].  Please cc me
> in patch pings if you haven't been able to get reviews and need attention.

What should we do about the built-in system call tables?  I think it's
desirable to have this in the release to get a well-defined system call
profile after the the Y2038 changes.  Otherwise, there will be a lot of
variance regarding the system calls glibc makes depending on which
version of the kernel headers glibc was built with.

  <https://sourceware.org/ml/libc-alpha/2019-12/msg00567.html>

The actual code changes (the first two patches) could go in before the
build-many-glibcs.py changes have been reviewed.  I think the updating
logic now follows Joseph's suggestion, but I don't know if the changes I
did on build-many-glibcs.py are acceptable from a consistency/style
perspective.

Thanks,
Florian

Reply | Threaded
Open this post in threaded view
|

Re: 2.31: < 2 weeks to go

Siddhesh Poyarekar-8
On 20/12/19 8:00 pm, Florian Weimer wrote:

> * Siddhesh Poyarekar:
>
>> Less than two weeks to go for 2.31 freeze.  I intend to announce a
>> freeze on 31st December around afternoon IST.  Here's a reminder that if
>> you'd like your patchset considered for inclusion during the freeze, it
>> needs to be in the blockers list on the release page[1].  Please cc me
>> in patch pings if you haven't been able to get reviews and need attention.
>
> What should we do about the built-in system call tables?  I think it's
> desirable to have this in the release to get a well-defined system call
> profile after the the Y2038 changes.  Otherwise, there will be a lot of
> variance regarding the system calls glibc makes depending on which
> version of the kernel headers glibc was built with.
>
>   <https://sourceware.org/ml/libc-alpha/2019-12/msg00567.html>
>
> The actual code changes (the first two patches) could go in before the
> build-many-glibcs.py changes have been reviewed.  I think the updating
> logic now follows Joseph's suggestion, but I don't know if the changes I
> did on build-many-glibcs.py are acceptable from a consistency/style
> perspective.

I took a quick look at the patches and the discussions earlier and it
looked to me like they're headed in the right direction.  Joseph, do you
agree?  If you don't have the bandwidth to do a full review, I can help
with that.

Siddhesh
Reply | Threaded
Open this post in threaded view
|

Re: 2.31: < 2 weeks to go

Joseph Myers
On Sun, 22 Dec 2019, Siddhesh Poyarekar wrote:

> > What should we do about the built-in system call tables?  I think it's
> > desirable to have this in the release to get a well-defined system call
> > profile after the the Y2038 changes.  Otherwise, there will be a lot of
> > variance regarding the system calls glibc makes depending on which
> > version of the kernel headers glibc was built with.
> >
> >   <https://sourceware.org/ml/libc-alpha/2019-12/msg00567.html>
> >
> > The actual code changes (the first two patches) could go in before the
> > build-many-glibcs.py changes have been reviewed.  I think the updating
> > logic now follows Joseph's suggestion, but I don't know if the changes I
> > did on build-many-glibcs.py are acceptable from a consistency/style
> > perspective.
>
> I took a quick look at the patches and the discussions earlier and it
> looked to me like they're headed in the right direction.  Joseph, do you
> agree?  If you don't have the bandwidth to do a full review, I can help
> with that.

The general approach seems plausible.  I don't expect much time for patch
review while working on the GCC git conversion.

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 2.31: < 2 weeks to go

Chung-Lin Tang
In reply to this post by Carlos O'Donell-5
On 2019/12/20 12:56 PM, Carlos O'Donell wrote:
> Chung-Lin,
>
> I suggest you also put the dynamic loader improvements on the blocker
> list. I've been look at these for months, and I haven't found anything
> really wrong with them. I need to post my review writeup, but I keep
> getting blocked. I'm going to do that either tomorrow or next week.

Thanks! I just added it to the 2.31 release Wiki page.

Happy Holidays,
Chung-Lin
Reply | Threaded
Open this post in threaded view
|

Re: 2.31: < 2 weeks to go

Carlos O'Donell-5
On 12/24/19 9:36 AM, Chung-Lin Tang wrote:
> On 2019/12/20 12:56 PM, Carlos O'Donell wrote:
>> Chung-Lin,
>>
>> I suggest you also put the dynamic loader improvements on the blocker
>> list. I've been look at these for months, and I haven't found anything
>> really wrong with them. I need to post my review writeup, but I keep
>> getting blocked. I'm going to do that either tomorrow or next week.
>
> Thanks! I just added it to the 2.31 release Wiki page.

Just posted my review notes:
https://www.sourceware.org/ml/libc-alpha/2019-12/msg00753.html

Thank you for your patience.

--
Cheers,
Carlos.

Reply | Threaded
Open this post in threaded view
|

Re: 2.31: < 2 weeks to go

Siddhesh Poyarekar-8
In reply to this post by Siddhesh Poyarekar-8
On 20/12/19 9:05 am, Siddhesh Poyarekar wrote:

> Hello folks,
>
> Less than two weeks to go for 2.31 freeze.  I intend to announce a
> freeze on 31st December around afternoon IST.  Here's a reminder that if
> you'd like your patchset considered for inclusion during the freeze, it
> needs to be in the blockers list on the release page[1].  Please cc me
> in patch pings if you haven't been able to get reviews and need attention.
>
> Siddhesh
>
> [1] https://sourceware.org/glibc/wiki/Release/2.31
>

This is tomorrow.  I'm traveling during the day, so I'll announce the
freeze tomorrow night, IST.

How are the release blockers doing?  Are they on target to being done in
the next day or do they need more time?

Florian, your syscall patchset is good to go with fixups to 1/5; would
you be able to post an updated set in the next day or two?  I think it's
good to go in for 2.31 if you're able to get the new patch out for
review soon.

Siddhesh
Reply | Threaded
Open this post in threaded view
|

Re: 2.31: < 2 weeks to go

Florian Weimer
* Siddhesh Poyarekar:

> Florian, your syscall patchset is good to go with fixups to 1/5; would
> you be able to post an updated set in the next day or two?

I hope so.  I have some trouble typing, so there hasn't been any
progress yet.
Reply | Threaded
Open this post in threaded view
|

Re: 2.31: < 2 weeks to go

Carlos O'Donell-5
In reply to this post by Chung-Lin Tang
On 12/24/19 9:36 AM, Chung-Lin Tang wrote:
> On 2019/12/20 12:56 PM, Carlos O'Donell wrote:
>> Chung-Lin,
>>
>> I suggest you also put the dynamic loader improvements on the blocker
>> list. I've been look at these for months, and I haven't found anything
>> really wrong with them. I need to post my review writeup, but I keep
>> getting blocked. I'm going to do that either tomorrow or next week.
>
> Thanks! I just added it to the 2.31 release Wiki page.

I finished my review, but in hindsight I've seen at least one odd
sorting which worries me, and so I think we need to move this to early
2.32. We should keep moving the review forward and aim to commit early
in February. This gives us the biggest window for finding problems.

In summary:
- Move ld.so improvements to 2.32.
- Aim to commit them in February.


Chung-Lin,

Would you like to split up the work a bit? I could take a look at
expanding the python syntax?

--
Cheers,
Carlos.