Community Patch Review Meeting: 2021-01-11 at 0900h EST (UTC-5)

Community Patch Review Meeting: 2021-01-11 at 0900h EST (UTC-5)

[Carlos O'Donell]

Meeting reminder:
https://sourceware.org/glibc/wiki/PatchworkReviewMeetings

I need to be away for personal reasons and Siddhesh has graciously
agreed to setup the meeting room.

Adhemerval,

As release manager would you mind running the agenda for the meeting?

Review of blockers and desirable patches worked well last week.

My apologies for the short notice.

I am working on having a backup host for the meeting so we can run
them continuously, but this isn't isn't resolved yet.

Thank you for your patience.

-- 
Cheers,
Carlos.

Re: Community Patch Review Meeting: 2021-01-11 at 0900h EST (UTC-5)

[Siddhesh Poyarekar]

On Mon, Jan 11, 2021 at 8:29 AM Carlos O'Donell <carlos@redhat.com> wrote:

> I am working on having a backup host for the meeting so we can run
> them continuously, but this isn't isn't resolved yet.

Now that I've found my FSF login I can volunteer to be the backup host.

Siddhesh

Re: Community Patch Review Meeting: 2021-01-11 at 0900h EST (UTC-5)

[Adhemerval Zanella]

On 11/01/2021 00:24, Siddhesh Poyarekar wrote:
> On Mon, Jan 11, 2021 at 8:29 AM Carlos O'Donell <carlos@redhat.com> wrote:
> 
>> I am working on having a backup host for the meeting so we can run
>> them continuously, but this isn't isn't resolved yet.
> 
> Now that I've found my FSF login I can volunteer to be the backup host.
> 
> Siddhesh
> 

Thanks Siddhesh, if you may I would ask to be the host.

Re: Community Patch Review Meeting: 2021-01-11 at 0900h EST (UTC-5)

[Siddhesh Poyarekar]

On Mon, Jan 11, 2021 at 5:35 PM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
>
> Thanks Siddhesh, if you may I would ask to be the host.

Oh yes, I'll make you co-host once you join but to start the call one
needs to login as an FSF member.  I only volunteered to help start the
call bridge whenever Carlos is unavailable to do that.

Siddhesh

Re: Community Patch Review Meeting: 2021-01-11 at 0900h EST (UTC-5)

[Adhemerval Zanella]

On 10/01/2021 23:59, Carlos O'Donell wrote:
> Meeting reminder:
> https://sourceware.org/glibc/wiki/PatchworkReviewMeetings
> 
> I need to be away for personal reasons and Siddhesh has graciously
> agreed to setup the meeting room.
> 
> Adhemerval,
> 
> As release manager would you mind running the agenda for the meeting?
> 
> Review of blockers and desirable patches worked well last week.
> 
> My apologies for the short notice.
> 
> I am working on having a backup host for the meeting so we can run
> them continuously, but this isn't isn't resolved yet.
> 
> Thank you for your patience.
> 

Hi Carlos, below some notes from the meeting today.  We focused solely
on the release blockers and desirable features for next 2.33 release, 
so patchwork backlog was not reviewed.

  1. x86: Move x86 processor cache info to cpu_features [1] and
     ld.so: Add --list-tunables to print tunable values [2]: H.J. Lu
     raised that both are already postpone from previous release and
     he would like to get this upstream since he is considering dropping
     if it could not make it for 2.33.

     Florian said he will check on this, but he wasn't sure it he will
     finish in time.  Both patches seems ok at first glance for me,
     although Siddhesh has raised some concerns about the 2nd patch
     loader change (and H.J.Lu noted that we did change the loader for
     the hwcap isa work recently).

  2. ld.so: DSO sorting algorithm patch, both testing infrastructure and 
     new algorithm [3][4]: Florian is not sure if this change would be fully
     reviewed for 2.33, so he is considering postponing to 2.34.

     Florian noted that the new implementation is not set as default,
     so it avoid possible disruptions and regressions.  I don't have a strong
     opinion here, so I would some input whether this is polished enough to
     glibc provide as a tunable. From maillist it seems it has been used
     in production by some developers and large deployments.

  3. sysconf: Add _SC_MINSIGSTKSZ/_SC_SIGSTKSZ [BZ #20305] [5] and
     Deprecate SIGSTKSZ/MINSIGSTKSZ with _SC_SIGSTKSZ_SOURCE [6]: this is
     required to accommodate a new kernel change on recent version accordingly
     to H.J. Lu.

     Florian has raised some question whether it should also change the
     per thread stack, but H.J said it is a different problem.

     H.J. also said the second patch [2] should be if first patch is pushed,
     to avoid developers use the old interface.

     I haven't followed in details task, so I would like some input on current
     status and if we will be on track for 2.33.

  4. ldconfig/x86: Store ISA level in cache and aux cache: this on me, I reviewed
     the first patch and I plan to wrap the ldconfig one this week.

  5. x86: The COMMON_CPUID_INDEX_MAX handshake does not work [BZ #27104] https [7].
     Florian state this is definitely a release blocker and he intend to review it.

  6. linux: mips: Fix getdents64 fallback on mips64-n32 [8]: this is a blocker for
     mips64-n32 to build on gcc11. Florian said it is on this list.

  7. stdlib: Add testcase for BZ #26241: the patches are upstream and it fixes all
     known realpatch issue.  This one is just a testcase to exercise the stack
     overflow from previous implementation, not really a blocker but it would be
     good to have.  I have moved it to desirable.

  8. posix: Sync tempname with gnulib (BZ #26648): Paul Eggert has pushed a fix
     on gnulib which I intended to use.  It is slight different from my proposal,
     which followed his own suggestion; so I am discussing with him why he hasn't
     followed his own suggestion...

  9. aarch64: fix static PIE ifunc resolvers: Szabolcs just send a new version
     along with a fix for a GCC8 issue.  I plan to review those this week.

  10. GCC 11 incompatibilities [10]: Florian stated it is a GCC bug, but we should
      track it.

  11. Add support for GCC 11 -Wmismatched-dealloc: Florian raised some questions
      whether this issue is polished enough to be pushed on glibc side.

[1] https://patchwork.sourceware.org/project/glibc/patch/20201031154437.2689427-2-hjl.tools@gmail.com/
[2] https://patchwork.sourceware.org/project/glibc/patch/20201031154437.2689427-3-hjl.tools@gmail.com/
[3] https://patchwork.sourceware.org/project/glibc/patch/91bd3ea0-7a03-df54-ea98-ef0f6d1304f1@codesourcery.com/
[4] https://patchwork.sourceware.org/project/glibc/patch/85ab188b-64c2-d1fd-33fa-d7d2e6fb2d97@codesourcery.com/
[5] https://patchwork.sourceware.org/project/glibc/patch/CAMe9rOo3FdwJV8fa=KcHa6VSqNexzgiiF2NS1uq=ay+bzMHpOw@mail.gmail.com/
[6] https://patchwork.sourceware.org/project/glibc/patch/CAMe9rOo3FdwJV8fa=KcHa6VSqNexzgiiF2NS1uq=ay+bzMHpOw@mail.gmail.com/
[7] https://patchwork.sourceware.org/project/glibc/patch/20201225162451.1657088-1-hjl.tools@gmail.com/
[8] https://patchwork.sourceware.org/project/glibc/patch/20201116211743.2228063-1-adhemerval.zanella@linaro.org/
[9] https://patchwork.sourceware.org/project/glibc/patch/20201229193454.34558-7-adhemerval.zanella@linaro.org/
[10] Bug 98512 - [11 Regression] “#pragma GCC diagnostic ignored” ineffective in conjunction with alias attribute
[11] https://sourceware.org/pipermail/libc-alpha/2020-December/120560.html

Re: Community Patch Review Meeting: 2021-01-11 at 0900h EST (UTC-5)

[Carlos O'Donell]

On 1/11/21 1:35 PM, Adhemerval Zanella wrote:
> 
> 
> On 10/01/2021 23:59, Carlos O'Donell wrote:
>> Meeting reminder:
>> https://sourceware.org/glibc/wiki/PatchworkReviewMeetings
>>
>> I need to be away for personal reasons and Siddhesh has graciously
>> agreed to setup the meeting room.
>>
>> Adhemerval,
>>
>> As release manager would you mind running the agenda for the meeting?
>>
>> Review of blockers and desirable patches worked well last week.
>>
>> My apologies for the short notice.
>>
>> I am working on having a backup host for the meeting so we can run
>> them continuously, but this isn't isn't resolved yet.
>>
>> Thank you for your patience.
>>
> 
> Hi Carlos, below some notes from the meeting today.  We focused solely
> on the release blockers and desirable features for next 2.33 release, 
> so patchwork backlog was not reviewed.

Thank you very much for helping with this.

I'm going to focus on my patch review and fixing the pthread condvar
bug we have floating around that we can't pin down.

-- 
Cheers,
Carlos.

Re: Community Patch Review Meeting: 2021-01-11 at 0900h EST (UTC-5)

[Siddhesh Poyarekar]

On Tue, Jan 12, 2021 at 12:05 AM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
>      Florian said he will check on this, but he wasn't sure it he will
>      finish in time.  Both patches seems ok at first glance for me,
>      although Siddhesh has raised some concerns about the 2nd patch
>      loader change (and H.J.Lu noted that we did change the loader for
>      the hwcap isa work recently).

Oh I did not have any specific concerns about the second patch because
I had not even seen it :)

What I said was that typically during freeze we limit non-bug-fix
changes to those that don't have a major impact on architecture and
distribution testing and that criteria may need to be applied to the
second patch.  It's your call to make as RM on whether to include it
or not, not mine.

>   2. ld.so: DSO sorting algorithm patch, both testing infrastructure and
>      new algorithm [3][4]: Florian is not sure if this change would be fully
>      reviewed for 2.33, so he is considering postponing to 2.34.

It was this patch that I specifically stated was IMO unsuitable for
inclusion during freeze since it would interfere with distro and
architecture testing schedules, but again it's your call as RM.  The
more important point I made was to encourage review of the patch so
that it is ready for inclusion the moment master opens again and
doesn't get forgotten.

In fact, I want to start a conversation on whether we should
reconsider this aspect of the release freeze process.  The freeze
process made sense 7-8 years ago when we were a smaller contributor
group and all of us would be focused on bug fixes and testing during
that time and there was little scope of us being able to review new
patches during that time.  We are a significantly larger group now, so
does it make sense to change the process to make the release branch at
the freeze point and continue development on master?  That way we
potentially allow development to continue on the master branch while
the release branch stabilizes.  Tentatively, the freeze point would
look like this:

1. RM calls freeze and asks everyone to stop commits to the repo
2. Make a release/2.x/master
3. Update VERSION to 2.x+1.9000 in master
4. Announce release branch on libc-alpha and reopen development

From this point on, development continues as normal on master.  For
inclusion in release/2.x/master, RM approval is necessary.

Siddhesh

Re: Community Patch Review Meeting: 2021-01-11 at 0900h EST (UTC-5)

[Adhemerval Zanella]

On 11/01/2021 23:52, Siddhesh Poyarekar wrote:
> On Tue, Jan 12, 2021 at 12:05 AM Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
>>      Florian said he will check on this, but he wasn't sure it he will
>>      finish in time.  Both patches seems ok at first glance for me,
>>      although Siddhesh has raised some concerns about the 2nd patch
>>      loader change (and H.J.Lu noted that we did change the loader for
>>      the hwcap isa work recently).
> 
> Oh I did not have any specific concerns about the second patch because
> I had not even seen it :)
> 
> What I said was that typically during freeze we limit non-bug-fix
> changes to those that don't have a major impact on architecture and
> distribution testing and that criteria may need to be applied to the
> second patch.  It's your call to make as RM on whether to include it
> or not, not mine.

My mistake then, I though you were referring this change specifically.

> 
>>   2. ld.so: DSO sorting algorithm patch, both testing infrastructure and
>>      new algorithm [3][4]: Florian is not sure if this change would be fully
>>      reviewed for 2.33, so he is considering postponing to 2.34.
> 
> It was this patch that I specifically stated was IMO unsuitable for
> inclusion during freeze since it would interfere with distro and
> architecture testing schedules, but again it's your call as RM.  The
> more important point I made was to encourage review of the patch so
> that it is ready for inclusion the moment master opens again and
> doesn't get forgotten.

Indeed, I don't have a strong opinion since its inclusion will be
as an optional feature instead of the default semantic.  But I 
agree with that my initial assessment would to postpone to 2.34
and push on initial development phase. 

> 
> In fact, I want to start a conversation on whether we should
> reconsider this aspect of the release freeze process.  The freeze
> process made sense 7-8 years ago when we were a smaller contributor
> group and all of us would be focused on bug fixes and testing during
> that time and there was little scope of us being able to review new
> patches during that time.  We are a significantly larger group now, so
> does it make sense to change the process to make the release branch at
> the freeze point and continue development on master?  That way we
> potentially allow development to continue on the master branch while
> the release branch stabilizes.  Tentatively, the freeze point would
> look like this:
> 
> 1. RM calls freeze and asks everyone to stop commits to the repo
> 2. Make a release/2.x/master
> 3. Update VERSION to 2.x+1.9000 in master
> 4. Announce release branch on libc-alpha and reopen development
> 
> From this point on, development continues as normal on master.  For
> inclusion in release/2.x/master, RM approval is necessary.

I though about that and the drawback of this procedure is we will either
will have to tag the release branch itself or the tag in master will
be incomplete.

Re: Community Patch Review Meeting: 2021-01-11 at 0900h EST (UTC-5)

[Siddhesh Poyarekar]

On 1/12/21 5:08 PM, Adhemerval Zanella via Libc-alpha wrote:
> I though about that and the drawback of this procedure is we will either
> will have to tag the release branch itself or the tag in master will
> be incomplete.

Yeah, I agree that is a drawback, but I wonder what's the disadvantage 
of having the tag on the branch rather than on the master branch.  Does 
it have any issues in any of our workflows?

Siddhesh

Re: Community Patch Review Meeting: 2021-01-11 at 0900h EST (UTC-5)

[Florian Weimer]

* Adhemerval Zanella:

>> In fact, I want to start a conversation on whether we should
>> reconsider this aspect of the release freeze process.  The freeze
>> process made sense 7-8 years ago when we were a smaller contributor
>> group and all of us would be focused on bug fixes and testing during
>> that time and there was little scope of us being able to review new
>> patches during that time.  We are a significantly larger group now, so
>> does it make sense to change the process to make the release branch at
>> the freeze point and continue development on master?  That way we
>> potentially allow development to continue on the master branch while
>> the release branch stabilizes.  Tentatively, the freeze point would
>> look like this:
>> 
>> 1. RM calls freeze and asks everyone to stop commits to the repo
>> 2. Make a release/2.x/master
>> 3. Update VERSION to 2.x+1.9000 in master
>> 4. Announce release branch on libc-alpha and reopen development
>> 
>> From this point on, development continues as normal on master.  For
>> inclusion in release/2.x/master, RM approval is necessary.
>
> I though about that and the drawback of this procedure is we will either
> will have to tag the release branch itself or the tag in master will
> be incomplete.

OpenJDK puts fixes on the release branch and merges the branch regularly
into the mainline branch.  This way, the release tag will also end up on
the mailine branch.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

Re: Community Patch Review Meeting: 2021-01-11 at 0900h EST (UTC-5)

[Adhemerval Zanella]

On 12/01/2021 08:49, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>>> In fact, I want to start a conversation on whether we should
>>> reconsider this aspect of the release freeze process.  The freeze
>>> process made sense 7-8 years ago when we were a smaller contributor
>>> group and all of us would be focused on bug fixes and testing during
>>> that time and there was little scope of us being able to review new
>>> patches during that time.  We are a significantly larger group now, so
>>> does it make sense to change the process to make the release branch at
>>> the freeze point and continue development on master?  That way we
>>> potentially allow development to continue on the master branch while
>>> the release branch stabilizes.  Tentatively, the freeze point would
>>> look like this:
>>>
>>> 1. RM calls freeze and asks everyone to stop commits to the repo
>>> 2. Make a release/2.x/master
>>> 3. Update VERSION to 2.x+1.9000 in master
>>> 4. Announce release branch on libc-alpha and reopen development
>>>
>>> From this point on, development continues as normal on master.  For
>>> inclusion in release/2.x/master, RM approval is necessary.
>>
>> I though about that and the drawback of this procedure is we will either
>> will have to tag the release branch itself or the tag in master will
>> be incomplete.
> 
> OpenJDK puts fixes on the release branch and merges the branch regularly
> into the mainline branch.  This way, the release tag will also end up on
> the mailine branch.

We will need to layout the merge strategies, but this seems to be used for
multiple projects (specially when community has a more active development).

I think we can discuss this for new release, since we will need to proper
document and change the release wiki page.