If you would like your name added or removed from this list, please do so yourself.

Becoming a maintainer (developer)

So you want to become a maintainer (developer) eh?

This is how you do it:

You're a maintainer (developers) now! Huzzah!

Project stewards (GNU package maintainers)

The following people have agreed to be responsible for glibc to the GNU Project (alphabetical order by last name):

These people are the GNU package maintainers of glibc, with the associated responsibilities. Other people listed are "developers" in GNU project terms.

Maintainers (developers) for libc

Write after Consensus and/or approval from machine or other subsystem maintainer (alphabetical order by last name):

Operating system port maintainers

Machine maintainers

Distribution Maintainers

At the distribution level there are developers who are responsible for glibc in their particular distribution. These developers are an excellent point of contact when we have distribution related issues or questions and they should be consulted on issues that have far reaching effects on the distributions.

In alphabetical order by distribution:

Maintainers for the website

Blanket commit with the understanding that consultation and discretion are required. We maintain two websites, the official FSF website and another site at that forwards to the FSF one. See the Website Maintenance.

Maintainers for the wiki

You need login to followed by the ability to edit /wiki/ to add or modify properties of the wiki. There should be no need to do this, but sometimes you want to customize groups or do something more advanced. The following people have access to do this:

Maintainers for Bugzilla

Changes to bugzilla should be discussed by the entire community.

Maintainers for linuxthreads add-on

Reviewers by component

The intent of this table is to record which project members are either interested in or consider themselves capable of reviewing changes in the respective components. The component list is taken from bugzilla, plus some extra areas of interest. Where someone is listed in the Maintainers column, they may at their discretion consider their own patches in that area to have consensus without waiting for third-party review, although other people may still review patches in that area and it may turn out that a patch by someone listed does not in fact have consensus and needs changing or reverting.





Roland McGrath


Carlos O'Donell


Roland McGrath, Thomas Schwinge


Petr Baudis (don't block on him)


Carlos O'Donell, Siddhesh Poyarekar


Roland McGrath


Joseph Myers, Siddhesh Poyarekar (for multiple precision bits)




Carlos O'Donell


Petr Baudis (don't block on him)



Joseph Myers

Joseph Myers


conform/ tests

Joseph Myers

Joseph Myers

concurrency issues

Torvald Riegel

security issues

Florian Weimer

Everything else

Carlos O'Donell

Accounts on

The glibc source is graciously hosted by Red Hat on You will need an account on before you can become a developer. Use this handy dandy form to make that request:

Source Control ACLs

Senior developers in the project are responsible for authorizing commit access (through ) to the glibc group for the glibc and glibc-ports repositories. Once you are in the glibc group you will have write access to the repositories. Developers requesting commit access should email , CC the senior developer granting access (the senior developer will acknowledge the authorization), and include your sourceware account name and that you would like glibc group access to commit to the glibc repository.

Contacting maintainers

The normal way to contact maintainers about bugs is via the Bugzilla Procedures. Important security-related bugs, where public notification may cause harm to users, can be reported privately to the maintainers via the abovementioned email addresses. People are also welcome to report bugs via more-formal approaches, e.g., the U.S. Computer Emergency Readiness Team (US-CERT). There is a formal channel between US-CERT and the GNU C library developers.

Common sense is advised for deciding how important a security-relevant bug is. Triage tools are available.

LinkedIn Group

We have a LinkedIn Group for GLIBC Developers. The group is moderated by Carlos O'Donell.

Ohloh Group

We have an Ohloh Project for tracking glibc. The project is moderated by Carlos O'Donell.