Becoming a maintainer (developer)

Start by signing a copyright assignment for glibc, that will allow you to contribute to the parts of the project that require copyright assignment (almost all of it except for locales).

Once you have established that you are doing good work and following the contribution checklist, you may be approved for commit access as a maintainer (developer). Talk to the senior developers and ask them if being a maintainer (developer) is right for you. If the senior developers agree, then proceed to the next step.

The first step towards commit access is to follow these instructions to get an account on sourceware.

Once you have a sourceware account ask one of the existing senior developers for authorize your commit access. If the existing senior developer authorizes you for commit access follow these instructions to get commit access.

Operating system port maintainers

Machine maintainers

A machine maintainer is responsible to the GNU C Library project for maintaining the support for their machine, and for supporting the users of that machine. In general this maintainership means that you have the discretion to assume consensus for a change of your own without waiting for review or comments on consensus. If the discussion shows there is no consensus after all then your change will need revising or reverting. This does not mean that all objections are relevant for establishing lack of consensus, e.g. if the reasons given are speculative, based on false analogies to other machines or a lack of understanding of the change and its context or themselves ignore other established consensus. Lastly keep in mind that sustained opposition may be ignored if it is not considered a substantial issue by an important part of the concerned developers.

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.

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 sourceware.org that forwards to the FSF one. See the Website Maintenance.

Maintainers for the wiki

You need shell access to sourceware.org followed by the ability to edit /wiki/glibc.py 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

Maintainers for linuxthreads add-on

The linuxthreads add-on is no longer being actively maintained. The last official maintainer was Daniel Jacobowitz (drow).

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.

Component

Reviewers

Maintainers

benchtests

Siddhesh Poyarekar

Siddhesh Poyarekar

build

Roland McGrath

dynamic-link

Carlos O'Donell

hurd

Roland McGrath, Thomas Schwinge

localedata

Petr Baudis (don't block on him)

malloc

Carlos O'Donell, Siddhesh Poyarekar

manual

Roland McGrath

math

Joseph Myers, Siddhesh Poyarekar (for multiple precision bits)

Joseph Myers

network

nis

nptl

Carlos O'Donell

nscd

Petr Baudis (don't block on him)

Siddhesh Poyarekar

regex

soft-fp

Joseph Myers

Joseph Myers

stdio

conform/ tests

Joseph Myers

Joseph Myers

concurrency issues

Torvald Riegel

security issues

Florian Weimer

Everything else

Carlos O'Donell

Accounts on Sourceware.org

The glibc source is graciously hosted by Red Hat on sourceware.org. You will need an account on sourceware.org before you can become a developer. Use this handy dandy form to make that request: http://sourceware.org/cgi-bin/pdw/ps_form.cgi

Source Control ACLs

Senior developers in the project are responsible for authorizing commit access (through overseers@sourceware.org ) 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 overseers@sourceware.org , 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; see Security Process for details.