libpthread removal in 2.34

[Carlos O'Donell]

On 3/11/21 2:21 PM, Florian Weimer wrote:
> * Carlos O'Donell:
> 
>> However, as you've seen, if the patch is very detailed it will take a lot of
>> time to get review and make progress. That's just the nature of the position
>> of glibc in the total software stack. I expect some of the patches to move
>> and refactor libpthread would get stuck so we'd naturally fall behind and miss
>> the 2.34 deadline.
>>
>> In summary:
>>
>> - There are a number of outstanding issues we can probably fix this release:
>>
>>   * 64-bit time_t
>>
>>   * Atomic fixes for TLS and the dynamic loader
>>
>>   * C.UTF-8 (implement shortcuts to avoid large locale)
>>
>>   I think that the atomic fixes for TLS in the dynamic loader would be helped
>>   by your current experience fixing NODELETE and rewriting parts for glibc-hwcaps.
>>   $0.02.
>>
>> - It would also be great to make some progress on libpthread removal such
>>   that the remaining work is doable in 2.35.
> 
> I'm not sure if you are trying to give a realistic assessment of the
> situation or describing a desired outcome.  Do you think further
> discussion is needed, or do you consider this settled (i.e., delay to
> 2.35 or some later version)?

Sorry, let me clarify my position a bit more.

tl;dr

I think we can remove libpthread in 2.34, but I think we need 1 developer to
help and 1 other reviewer to help and commit to doing it in 2.34.

Details:

(1) libpthread removal in 2.34.

- Requires 15 interfaces per week.
- Requires 1 dedicated developer to do the work.
  - You suggest we swap between reviews and work, but not parallelize
    due to the nature of teh work.
- Requires 1 dedicated reviewer.
  - I raised the question about accelerating reviews for work like this in Feb 2020:
    "Consensus on high-level objective of cleanup, refactor or rework patches."
    https://sourceware.org/pipermail/libc-alpha/2020-February/111118.html
  - Joseph suggested being more tactical with review:
    https://sourceware.org/pipermail/libc-alpha/2020-February/111140.html
    ~~~
    On Fri, 14 Feb 2020, Carlos O'Donell wrote:

    > Reviewers, like myself, should consider reviewing *less* when it is
    > clearly evident that additional review is not required?

    Yes.  Consider what it is about the patch that is relevant to review, 
    taking into account factors such as existing consensus for an overall 
    design, any relevant expertise of the patch submitter and the quality and 
    contents of the commit message and the testing described in that commit 
    message.
    ~~~

I think we can do the libpthread reviewing if we get:
- At least 2 developers to work together to distribute work.
- At least 2 dedicated reviewers to distribute work.

As of today I could setup a dedicated review slot for this work where I do
only this review, but I would want a backup reviewer so I could negotiate
time off and swapping reviews.

It looks like Adhemerval is willing to support the work, but I'd like another
reviewer to help me with the review load. Would you suggest anyone else?
My immediate suggestion is to ask Szabolcs or DJ for weekly review, both of
them have been through larger reviews and understand what needs reviewing.

(2) If we don't do libpthread removal in 2.34, I can suggest some other projects.

- See my notes in the original email.

-- 
Cheers,
Carlos.