MAINTAINERS

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

Contents

  1. MAINTAINERS
    1. Contributing to glibc
    2. Becoming a maintainer (developer)
    3. Project stewards (GNU package maintainers)
    4. Maintainers (developers) for libc
      1. Operating system port maintainers
      2. Machine maintainers
    5. Distribution Maintainers
    6. Maintainers for the mailing lists
    7. Maintainers for the website
    8. Maintainers for the wiki
    9. Maintainers for the patchwork instance
    10. Maintainers for the git hooks
    11. Maintainers for Bugzilla
    12. Maintainers for linuxthreads add-on
    13. Maintainers for BuildBot
    14. Reviewers by component
    15. Accounts on Sourceware.org and source control ACLs
    16. Contacting maintainers
    17. LinkedIn Group
    18. Open HUB Group

Contributing to glibc

It all starts with one contribution. Anyone can contribute.

Please follow the Contribution Checklist: https://sourceware.org/glibc/wiki/Contribution%20checklist

Becoming a maintainer (developer)

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

Becoming a maintainer (developer) is a set of extra steps that allows you to work more closely with the community on glibc development.

You can create a patchwork account, or a wiki account, or even establish you are doing good work without becoming a maintainer.

This is how you do it:

  1. Get yourself a patchwork account on patchwork.sourceware.org and go through the Patch Review Workflow. Once you have an account ask one of the patchwork admins to give you permission to edit patches.

  2. Get yourself a wiki account and verify that you can edit the wiki. WARNING: Your account will be purged if you do not verify your account (spam prevention to avoid the database filling up with spam users).

  3. Establish you are doing good work.
    • 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 project stewards and ask them if being a maintainer (developer) is right for you. If the project steward agrees, then proceed to the next step.
  4. Ask for commit access.
    • Ask one of the project stewards to authorize your commit access.

    • If the project steward authorizes you for commit access follow these instructions to create a sourceware account with commit access to the glibc repository.

  5. Add yourself to the maintainers list.

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.

You can reach out to the stewards directly and privately with your questions or comments by sending email to [email protected].

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

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.

In alphabetical order by distribution:

Maintainers for the mailing lists

The mailing lists for glibc are maintained on sourceware. The current maintainers that can configure the ezmlm mailing lists are:

Maintainers for the website

Blanket commit with the understanding that consultation and discretion are required. We maintain two websites, the official FSF website and main site at sourceware.org. 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 the patchwork instance

You need login to sourceware.org for the patchwork user.

Maintainers for the git hooks

You need shell access to sourceware.org followed by the ability to edit /git/glibc.git/hooks/* to change the hooks.

Maintainers for Bugzilla

Changes to bugzilla should be discussed by the entire community.

As an anti-spam measure creating new bugzilla accounts and the ability to edit certain fields of created bugs is not possible e.g. 'editbugs' is restricted by default. If you would like to create a new bugzilla account please ask [email protected]. If you like 'editbugs' capabilities please just ask on [email protected]. There are several people in the community which can grant this permission including anyone with a @debian.org, @fedora.org, @gentoo.org, @gnu.org, @redhat.com, @sourceware.org, @suse.com, @suse.de, or @ubuntu.com accounts in bugzilla. Just ask.

Maintainers for linuxthreads add-on

Maintainers for BuildBot

The following people have access to the BuildBot server and can help you to integrate BuildBot-related patches.

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

dynamic-link

Carlos O'Donell

hurd htl

Thomas Schwinge, Samuel Thibault

localedata

Petr Baudis (don't block on him)

Mike Fabian, Rafał Lużyński

malloc

Carlos O'Donell, Siddhesh Poyarekar, DJ Delorie

manual

math

Joseph Myers

Joseph Myers

network

Florian Weimer

nis

nptl

Carlos O'Donell

nscd

Petr Baudis (don't block on him), DJ Delorie

nss

Carlos O'Donell

regex

soft-fp

Joseph Myers

Joseph Myers

stdio

conform/ tests

Joseph Myers

Joseph Myers

concurrency issues

Torvald Riegel

security issues

Florian Weimer, Siddhesh Poyarekar

tunables

Siddhesh Poyarekar

Everything else

Carlos O'Donell

Accounts on Sourceware.org and source control ACLs

The glibc project is graciously hosted on sourceware. Project stewards are responsible for authorizing commit access 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. 

TO: [email protected]
CC: <glibc project steward>

Overseers,

Please add me (<your sourceware username>) to the glibc group after verifying with <glibc project steward>.

<glibc project steward> vouches for my sanity and competence.

I truly understand FSF copyright protocols, and always respect per-branch policies on what I am allowed to touch and how.

Thank you,

<your name>

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 "Reporting security issues" for details.

LinkedIn Group

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

Open HUB Group

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

None: MAINTAINERS (last edited 2024-11-21 17:19:32 by AndrewPinski)