glibc 2.27: two weeks left of active development

glibc 2.27: two weeks left of active development

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 180 bytes --]

Hi,

This is a gentle reminder that there are just two weeks left of active
development before the freeze window is January 2018 with a release
on February 1st.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: glibc 2.27: two weeks left of active development

[H.J. Lu]

On Sun, Dec 17, 2017 at 3:14 PM, Dmitry V. Levin <ldv@altlinux.org> wrote:
> Hi,
>
> This is a gentle reminder that there are just two weeks left of active
> development before the freeze window is January 2018 with a release
> on February 1st.

We are very close to finish Intel CET support.  The last remaining pieces are

1. Kernel interface.
2. Disallow makecontext family functions with -mshstk.

We hope to finish them next week.


-- 
H.J.

Re: glibc 2.27: two weeks left of active development

[Joseph Myers]

On Mon, 18 Dec 2017, Zack Weinberg wrote:

> On Sun, Dec 17, 2017 at 6:14 PM Dmitry V. Levin <ldv@altlinux.org> wrote:
> 
> > This is a gentle reminder that there are just two weeks left of active
> > development before the freeze window is January 2018 with a release
> > on February 1st.
> 
> 
> I'm not going to be able to shepherd it any more myself, but I would really
> like to see Rafal's patches for alternative month names in strftime make it
> in this cycle.

I would suggest such features looking for review go in the "Desirable this 
release" section on <https://sourceware.org/glibc/wiki/Release/2.27> (with 
appropriate links to the most recent patch version and discussions 
thereof).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: glibc 2.27: two weeks left of active development

[Joseph Myers]

I would like to remind anyone hoping to get a new architecture port (e.g. 
ARC or RISC-V) into 2.27 that, while it may be possible for a port to go 
in after the start of the freeze provided it's clear it can't affect 
existing ports and there's still time to provide test results for the port 
before the release, it's also likely that a port will require several 
rounds of patch review and resubmission, and in particular the review 
process ought to be well in progress before the freeze starts.  So please 
submit any new ports you want in 2.27 as soon as possible.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: glibc 2.27: two weeks left of active development

[Palmer Dabbelt]

On Mon, 18 Dec 2017 09:31:22 PST (-0800), joseph@codesourcery.com wrote:
> I would like to remind anyone hoping to get a new architecture port (e.g.
> ARC or RISC-V) into 2.27 that, while it may be possible for a port to go
> in after the start of the freeze provided it's clear it can't affect
> existing ports and there's still time to provide test results for the port
> before the release, it's also likely that a port will require several
> rounds of patch review and resubmission, and in particular the review
> process ought to be well in progress before the freeze starts.  So please
> submit any new ports you want in 2.27 as soon as possible.

Thanks for the reminder.  I'll try to submit our port ASAP.

Re: glibc 2.27: two weeks left of active development

[Zack Weinberg]

[Resending this message which did not make it to the list.  Apologies
if you see it twice.]

On Sun, Dec 17, 2017 at 6:14 PM, Dmitry V. Levin <ldv@altlinux.org> wrote:
>
> This is a gentle reminder that there are just two weeks left of active
> development before the freeze window is January 2018 with a release
> on February 1st.

I'm not going to be able to shepherd it any more myself, but I would
really like to see Rafal's patches for alternative month names in
strftime make it in this cycle.

zw

Re: glibc 2.27: two weeks left of active development

[Carlos O'Donell]

On 12/18/2017 09:35 AM, Palmer Dabbelt wrote:
> On Mon, 18 Dec 2017 09:31:22 PST (-0800), joseph@codesourcery.com wrote:
>> I would like to remind anyone hoping to get a new architecture port (e.g.
>> ARC or RISC-V) into 2.27 that, while it may be possible for a port to go
>> in after the start of the freeze provided it's clear it can't affect
>> existing ports and there's still time to provide test results for the port
>> before the release, it's also likely that a port will require several
>> rounds of patch review and resubmission, and in particular the review
>> process ought to be well in progress before the freeze starts.  So please
>> submit any new ports you want in 2.27 as soon as possible.
> 
> Thanks for the reminder.  I'll try to submit our port ASAP.

It's less about "ASAP" and more about "Do you think it's ready to go in
right now in 2.27?"

By submitting it for 2.27 you have the following consequences:

* You need to convince maintainers for review during a precious period
  of time when we're preparing the release and handling bugs.

* You need to have confidence your port is ready and you haven't made
  any real ABI mistakes. Any last minute mistakes that slip through
  will become permanent ABI artifacts for the port.

Instead if you submit your patches for 2.28 you have the following
consequences:

* The good will of the maintainers who know they can review your
  patches with time, looking for ABI issues.

* Get the patches into 2.28 early, and allow for testing before
  the 2.28 release on August 1st 2018. This will iron out any ABI
  issues before release.

I have purposely slanted my bias in this explanation :-)

-- 
Cheers,
Carlos.

Re: glibc 2.27: two weeks left of active development

[Carlos O'Donell]

On 12/18/2017 09:42 AM, Zack Weinberg wrote:
> [Resending this message which did not make it to the list.  Apologies
> if you see it twice.]
> 
> On Sun, Dec 17, 2017 at 6:14 PM, Dmitry V. Levin <ldv@altlinux.org> wrote:
>>
>> This is a gentle reminder that there are just two weeks left of active
>> development before the freeze window is January 2018 with a release
>> on February 1st.
> 
> I'm not going to be able to shepherd it any more myself, but I would
> really like to see Rafal's patches for alternative month names in
> strftime make it in this cycle.

Rafal needs to:

* Update his patches, and ping.
* Put links to the patches in the "desirable for release" section of
  the release wiki page.

With that done, the senior maintainers can look and see what needs review
and how we allocate our time for review.

-- 
Cheers,
Carlos.

Re: glibc 2.27: two weeks left of active development

[Zack Weinberg]

On Mon, Dec 18, 2017 at 9:44 AM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 12/18/2017 09:42 AM, Zack Weinberg wrote:
>> [Resending this message which did not make it to the list.  Apologies
>> if you see it twice.]
>>
>> On Sun, Dec 17, 2017 at 6:14 PM, Dmitry V. Levin <ldv@altlinux.org> wrote:
>>>
>>> This is a gentle reminder that there are just two weeks left of active
>>> development before the freeze window is January 2018 with a release
>>> on February 1st.
>>
>> I'm not going to be able to shepherd it any more myself, but I would
>> really like to see Rafal's patches for alternative month names in
>> strftime make it in this cycle.
>
> Rafal needs to:
>
> * Update his patches, and ping.

He has done this (most recently on Dec 12).

> * Put links to the patches in the "desirable for release" section of
>   the release wiki page.

I added a link to the most recently posted patchset.

zw

Re: glibc 2.27: two weeks left of active development

[Joseph Myers]

On Mon, 18 Dec 2017, Carlos O'Donell wrote:

> By submitting it for 2.27 you have the following consequences:
> 
> * You need to convince maintainers for review during a precious period
>   of time when we're preparing the release and handling bugs.

That's basically why postponing submission until the actual freeze period 
would be a bad idea.  If you think a port is ready for 2.27 and want it in 
2.27, you should really be submitting it in the next few days so review 
can start before the freeze.  And the submission should have all the 
information needed, such as results from full glibc test runs for each 
supported ABI or other relevant configuration (using upstream GCC and 
binutils, with versions used specified) and confirmation that compilation 
test results for all the build-many-glibcs.py configurations added are 
clean (given use of suitable upstream versions of GCC / binutils / Linux 
kernel).  And now details of the state of static PIE support should be 
provided as well (may be absent or untested, but say so explicitly if so 
as that implies it needs listing on the PortStatus page as such).

> * You need to have confidence your port is ready and you haven't made
>   any real ABI mistakes. Any last minute mistakes that slip through
>   will become permanent ABI artifacts for the port.

There are always infelicities in the ABI that mean future changes need 
compat symbols for existing ports.  Provided the kernel port is upstream 
(and thus the kernel/userspace ABI is known and stable), which I think we 
agreed is a basic requirement for getting a glibc port upstream (the 
kernel port should at a minimum be in linux-next and expected to be in 
Linus's tree for the next release), and provided the glibc test results 
are reasonable (I've suggested < 20 architecture-specific failures, using 
upstream GCC and binutils, with no failures in the compilation tests), I 
don't think the ABI provides a particular reason to aim for a given 
release cycle or not.  Of course ABI issues need to be considered in the 
review, and the port submission should explain what ABIs are supported by 
the port (including details of e.g. whether hard-float and soft-float are 
different ABIs, if applicable).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: glibc 2.27: two weeks left of active development

[Joseph Myers]

On Mon, 18 Dec 2017, Carlos O'Donell wrote:

> Rafal needs to:
> 
> * Update his patches, and ping.
> * Put links to the patches in the "desirable for release" section of
>   the release wiki page.

I would suggest it would also be good to consider C11 threads similarly as 
desirable to have reviewed before the freeze.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: glibc 2.27: two weeks left of active development

[Palmer Dabbelt]

On Mon, 18 Dec 2017 09:42:55 PST (-0800), carlos@redhat.com wrote:
> On 12/18/2017 09:35 AM, Palmer Dabbelt wrote:
>> On Mon, 18 Dec 2017 09:31:22 PST (-0800), joseph@codesourcery.com wrote:
>>> I would like to remind anyone hoping to get a new architecture port (e.g.
>>> ARC or RISC-V) into 2.27 that, while it may be possible for a port to go
>>> in after the start of the freeze provided it's clear it can't affect
>>> existing ports and there's still time to provide test results for the port
>>> before the release, it's also likely that a port will require several
>>> rounds of patch review and resubmission, and in particular the review
>>> process ought to be well in progress before the freeze starts.  So please
>>> submit any new ports you want in 2.27 as soon as possible.
>>
>> Thanks for the reminder.  I'll try to submit our port ASAP.
>
> It's less about "ASAP" and more about "Do you think it's ready to go in
> right now in 2.27?"
>
> By submitting it for 2.27 you have the following consequences:
>
> * You need to convince maintainers for review during a precious period
>   of time when we're preparing the release and handling bugs.
>
> * You need to have confidence your port is ready and you haven't made
>   any real ABI mistakes. Any last minute mistakes that slip through
>   will become permanent ABI artifacts for the port.
>
> Instead if you submit your patches for 2.28 you have the following
> consequences:
>
> * The good will of the maintainers who know they can review your
>   patches with time, looking for ABI issues.
>
> * Get the patches into 2.28 early, and allow for testing before
>   the 2.28 release on August 1st 2018. This will iron out any ABI
>   issues before release.
>
> I have purposely slanted my bias in this explanation :-)

I think it's ready for 2.27, I just wanted to get some time to take some time 
to go over the port to solve some outstanding cruft.  Unfortunately it's been 
super busy here so I don't think I'll get a chance to do that.

I'll try to take a look tonight and then send it out early this week.

Re: glibc 2.27: two weeks left of active development

[Zack Weinberg]

On Mon, Dec 18, 2017 at 10:00 AM, Joseph Myers <joseph@codesourcery.com> wrote:
>
> I would suggest it would also be good to consider C11 threads similarly as
> desirable to have reviewed before the freeze.

I concur.  Those patches have been waiting a long time; I suspect
nobody feels qualified to review them.  I know I don't.

zw

Re: glibc 2.27: two weeks left of active development

[Palmer Dabbelt]

On Mon, 18 Dec 2017 09:58:16 PST (-0800), joseph@codesourcery.com wrote:
> On Mon, 18 Dec 2017, Carlos O'Donell wrote:
>
>> By submitting it for 2.27 you have the following consequences:
>>
>> * You need to convince maintainers for review during a precious period
>>   of time when we're preparing the release and handling bugs.
>
> That's basically why postponing submission until the actual freeze period
> would be a bad idea.  If you think a port is ready for 2.27 and want it in
> 2.27, you should really be submitting it in the next few days so review
> can start before the freeze.  And the submission should have all the
> information needed, such as results from full glibc test runs for each
> supported ABI or other relevant configuration (using upstream GCC and
> binutils, with versions used specified) and confirmation that compilation
> test results for all the build-many-glibcs.py configurations added are
> clean (given use of suitable upstream versions of GCC / binutils / Linux
> kernel).  And now details of the state of static PIE support should be
> provided as well (may be absent or untested, but say so explicitly if so
> as that implies it needs listing on the PortStatus page as such).

We're in Linux, the first tarball release will be 4.15.  We've been in GCC 
since 7.1.0 and binutils since 2.28, but it'll be a bit saner to use 7.3.0 and 
2.30.

I'll include this in the messages.

>> * You need to have confidence your port is ready and you haven't made
>>   any real ABI mistakes. Any last minute mistakes that slip through
>>   will become permanent ABI artifacts for the port.
>
> There are always infelicities in the ABI that mean future changes need
> compat symbols for existing ports.  Provided the kernel port is upstream
> (and thus the kernel/userspace ABI is known and stable), which I think we
> agreed is a basic requirement for getting a glibc port upstream (the
> kernel port should at a minimum be in linux-next and expected to be in
> Linus's tree for the next release), and provided the glibc test results
> are reasonable (I've suggested < 20 architecture-specific failures, using
> upstream GCC and binutils, with no failures in the compilation tests), I
> don't think the ABI provides a particular reason to aim for a given
> release cycle or not.  Of course ABI issues need to be considered in the
> review, and the port submission should explain what ABIs are supported by
> the port (including details of e.g. whether hard-float and soft-float are
> different ABIs, if applicable).

OK, I'll include all this.

Re: glibc 2.27: two weeks left of active development

[Joseph Myers]

On Mon, 18 Dec 2017, Palmer Dabbelt wrote:

> I think it's ready for 2.27, I just wanted to get some time to take some time
> to go over the port to solve some outstanding cruft.  Unfortunately it's been

The question is whether that cruft affects the ABI in an 
architecture-specific way, so can't be changed after there's been a 
release and might provide a case for delaying inclusion, or whether it's 
something that can sensibly be cleaned up later.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: glibc 2.27: two weeks left of active development

[Carlos O'Donell]

On 12/18/2017 10:03 AM, Zack Weinberg wrote:
> On Mon, Dec 18, 2017 at 10:00 AM, Joseph Myers <joseph@codesourcery.com> wrote:
>>
>> I would suggest it would also be good to consider C11 threads similarly as
>> desirable to have reviewed before the freeze.
> 
> I concur.  Those patches have been waiting a long time; I suspect
> nobody feels qualified to review them.  I know I don't.

I *make* myself qualified :-}

Please add them to the wiki.

-- 
Cheers,
Carlos.

Re: glibc 2.27: two weeks left of active development

[Palmer Dabbelt]

On Mon, 18 Dec 2017 10:08:36 PST (-0800), joseph@codesourcery.com wrote:
> On Mon, 18 Dec 2017, Palmer Dabbelt wrote:
>
>> I think it's ready for 2.27, I just wanted to get some time to take some time
>> to go over the port to solve some outstanding cruft.  Unfortunately it's been
>
> The question is whether that cruft affects the ABI in an
> architecture-specific way, so can't be changed after there's been a
> release and might provide a case for delaying inclusion, or whether it's
> something that can sensibly be cleaned up later.

I think everything is internal to glibc, as far as I know the ABI is sane.

Re: glibc 2.27: two weeks left of active development

[Adhemerval Zanella]

On 18/12/2017 16:09, Carlos O'Donell wrote:
> On 12/18/2017 10:03 AM, Zack Weinberg wrote:
>> On Mon, Dec 18, 2017 at 10:00 AM, Joseph Myers <joseph@codesourcery.com> wrote:
>>>
>>> I would suggest it would also be good to consider C11 threads similarly as
>>> desirable to have reviewed before the freeze.
>>
>> I concur.  Those patches have been waiting a long time; I suspect
>> nobody feels qualified to review them.  I know I don't.
> 
> I *make* myself qualified :-}
> 
> Please add them to the wiki.
> 

Thanks Carlos!

Re: glibc 2.27: two weeks left of active development

[Rafal Luzynski]

18.12.2017 05:03 Zack Weinberg <zackw@panix.com> wrote:
> 
>  On Sun, Dec 17, 2017 at 6:14 PM Dmitry V. Levin <ldv@altlinux.org
> mailto:ldv@altlinux.org> wrote:
>    
> > This is a gentle reminder that there are just two weeks left of active
> > development before the freeze window is January 2018 with a release
> > on February 1st.
> >  
>   
>  I'm not going to be able to shepherd it any more myself, but I would really
> like to see Rafal's patches for alternative month names in strftime make it
> in this cycle.
>   
>  zw

Thank you Zack for your previous reviews, thank you for this reminder, and
thank you for saying that you can't review any more so I know I must ask
others.
 

18.12.2017 18:51 Zack Weinberg <zackw@panix.com> wrote:
>
> On Mon, Dec 18, 2017 at 9:44 AM, Carlos O'Donell <carlos@redhat.com> wrote:
> > [...]
> > Rafal needs to:
> >
> > * Update his patches, and ping.
>
> He has done this (most recently on Dec 12).

True. [1]  Thank you again for replying.

Carlos, what kind of update do you mean?  Indeed, I am concerned about
some documentation issues, mainly the changelog and commit messages.
I will write more in the proper thread.  But I'm not aware of anything
else which needs to be updated.

> > * Put links to the patches in the "desirable for release" section of
> > the release wiki page.
>
> I added a link to the most recently posted patchset.
>
> zw

Finally, thank you for adding a link.

Actually, the most up-to-date version is in my github fork [2] because it
is the easiest way to keep the patches updated but it is not the official
way to submit them to glibc.

Regards,

Rafal


[1] https://sourceware.org/ml/libc-alpha/2017-12/msg00391.html
[2] https://github.com/rluzynski/glibc