Re: Nominations for Anthropic’s Claude for Open Source program

On 15/06/26 18:35, Andrew Pinski wrote:
> On Mon, Jun 15, 2026 at 2:17 PM Carlos O'Donell <[email protected]> wrote:
>> If anything in the face of LLMs I want to double down on actively
>> mentoring more developers to FOSS development.
> 
> When a newcoming came in asking for things to do last month, what was
> given is most likely overwheling for them and never responded again.
> https://inbox.sourceware.org/libc-alpha/CAFPohwASPGQHreidwNTR3Eo81f_TfsajkF0sH2qZFKqSUQ47mg@mail.gmail.com/

Sorry if I was too brief and potentially not welcoming; I could have spent 
some time digging into potential work and writing down better ideas. So I 
will take the opportunity and write them down:

1. Testing 

The testing would aim to both improve libsupport (the support/ subfolder) by 
consolidating internal functions (as LTP does for its testing) and add new 
tests to cover missing symbols or functionality. We now have container support, 
so we can extend testing for functionality that requires a more complex system 
setup.

Also, check whether the tests can be improved in terms of coverage and/or time 
spent. I started focusing on this area, and it culminated in a patchset to improve 
test scalability [1]. One issue with this kind of work is that it requires a lot
of GNU Make knowledge, but we do have many internal examples, especially new 
tests, on how to improve coverage and write better tests. 

One possible subproject is to document how to properly write glibc tests using 
libsupport and/or adapt the remaining one to use it. There are still around 30 
tests that use the old test-skeleton.c - 12 in libio/, the rest scattered across 
stdlib, rt, resolv, posix, nptl, io. 


2. Benchmarking

Another possible project is to improve benchmarks (benchmark subfolder), which
is currently cumbersome, quite hard to read, and somewhat difficult to parse. 
It would be really interesting to follow something like Google Benchmark [2],
which has many terminal color gimmicks, but focuses on providing proper, 
meaningful information without the need for extra parsing or using the bench 
scripts.


3. Documentation

Document undocumented functions in the manual. The manual/ has 55 .texi files
and a long tail of installed functions with no entry. Pick a small family (e.g. 
some wcs*, mkostemp variants, newer C23 additions), write the texinfo. This 
also has zero ABI risk, and is easy to review.


4. Compiler-warning / new-GCC cleanups

Build with a newer GCC or stricter flags and fix the warnings in one subdirectory. 
Bounded, and a good way to learn the -Werror discipline glibc enforces. 

Another possibility is to check which backports are required to enable the old 
release branch to build cleanly with newer GCC versions.


5. Add missing header annotations

Check new gcc/clang annotations  (__wur, __nonnull, __attribute_malloc__) and
apply them where clearly correct. Small but needs care — must not introduce 
false-positive  warnings in the test suite, which would teach the newcomer to 
actually run make check.


6. Internal script cleanup

This might be a more contentious one, but I think we can reduce our build 
dependencies by at least rewriting the Perl script to either awk or Python.



There are small (1 to 2 weeks' work) projects that I think are good for newcomers. 
Below are some medium-sized (2-6 weeks' work) projects that require some more 
internal knowledge and research:


7. C23 conformance gaps 

The implementation of C23 is nearly complete, so the remaining work is mostly 
conformance testing and coverage: cross-check against Joseph Myers's C23 status 
tracker on libc-alpha, find the few stragglers, and write the missing conform/ 
tests. Good intro to the standards machinery without needing to design new ABI.


8. Resolver/getaddrinfo test coverage using support/resolv_test.h

Plenty of resolver behavior is under-tested; the framework lets a newcomer spin 
up a fake in-process DNS server. Medium because the domain is fiddly, but the 
tooling is already built.

And I can work on mentoring if someone is willing to work on any of this work.

> 
> I even pointed out in the news letter when referering to this email
> that "this newsletter could use some easy issues of the week for glibc
> and a mentor to reach out to for it":
> https://inbox.sourceware.org/libc-alpha/CAHt=NyPLDnHzbsV8xc7TC9Us9Djg6sDMo+QqKpbg0Kgnp6MzRw@mail.gmail.com/
> 

Well, I did reach out to you, but your reply made it seem like you would take 
care of it yourself [3]. In any case, if you are will I can help you with 
the glibc side of the weekly news.

> But nothing, not even saying let me get back to you on this. Not even
> a word. So I don't see any double down on this at all from you. In
> fact I just see inaction from you.
> 
> Thanks,
> Andrea

[1] https://patchwork.sourceware.org/project/glibc/list/?series=62266
[2] https://github.com/google/benchmark
[3] https://gcc.gnu.org/pipermail/gcc/2025-September/246616.html