Differences between revisions 81 and 175 (spanning 94 versions)
Revision 81 as of 2013-06-08 14:12:21
Size: 8804
Comment:
Revision 175 as of 2019-04-05 15:35:00
Size: 14845
Comment:
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:

== Becoming a maintainer ==

So you want to become a maintainer eh?
<<Anchor(Becoming_a_developer)>>
== Becoming a maintainer (developer) ==
So you want to become a maintainer (developer) eh?
Line 12: Line 11:
 * Start by signing a [[Contribution checklist#FSF_copyright_Assignment|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. Talk to the senior developers and ask them if being a maintainer is right for you. If the senior developers agree, then proceed to the next step.

 * The first step towards commit access is to follow [[#AccountOnSourceware|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 [[#SourceControlACL|these instructions]] to get commit access.

 * Once you have commit access you should immediately add yourself to [[#Maintainers|the list of maintainers]]. If you can't edit this page you should [[HomePage#EditingTheWiki|follow these instructions]] to get edit access to the wiki.

You're a maintainer now! Huzzah!

== Maintainers for libc and ports add-on ==
<<Anchor(Maintainers)>>
Write after [[Consensus]] and/or approval from machine maintainer (alphabetical order by last name):
 1. Start by signing a [[Contribution checklist#FSF_copyright_Assignment|copyright assignment]] for glibc.
    * Signing a copyright assignment will allow you to contribute to the parts of the project that require copyright assignment (almost all of it except for locales).

 1. Get yourself a patchwork account on [[http://patchwork.sourceware.org|patchwork.sourceware.org]] and go through the [[Patch Review Workflow]]

 1. Get yourself a wiki account and verify that you can [[https://sourceware.org/glibc/wiki/EditorGroup|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).

 1. 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.

 1. Get yourself a sourceware account. Follow [[#AccountsOnSourceware|these instructions]] to get an account on sourceware.

 1. 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 [[#SourceControlACL|these instructions]] to get commit access.

 1. Add yourself to the maintainers list.
    * Once you have commit access you should immediately add yourself to [[#Maintainers|the list of maintainers (developers)]]. If you can't edit this page you should [[HomePage#EditingTheWiki|follow these instructions]] to get edit access to the wiki.

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):
Line 29: Line 35:
 * Jeff Bailey (jbailey)  * Mark Brown
 * Paul Eggert (eggert)
 * Jakub Jelinek (jakub)
 * Maxim Kuvyrkov (maximk,mkuvyrkov)
 * Joseph Myers ([[JosephMyers|jsm28]])
 * Carlos O'Donell ([[CarlosODonell|carlos]])
 * Alexandre Oliva (aoliva)
 * Andreas Schwab (schwab)

These people are the GNU package maintainers of glibc, with the [[http://www.gnu.org/prep/maintain/maintain.html|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 libc-maintainers@gnu.org.

== Maintainers (developers) for libc ==
<<Anchor(Maintainers)>> Write after [[Consensus]] and/or approval from machine or other subsystem maintainer (alphabetical order by last name):

 * Dave Anglin (danglin)
 * Albert Aribaud (aaribaud)
 * Ryan S. Arnold (rsa,ryanarn)
Line 32: Line 56:
 * Christian Brauner (brauner)
Line 33: Line 58:
 * Paul Clarke (pc)
 * DJ Delorie (dj)
 * Liubov Dmitrieva (ldmitrie)
Line 35: Line 63:
 * Mike Frysinger (vapier)  * Mike Fabian (mfabian)
 * Mike Frysinger ([[MikeFrysinger|vapier]])
 * Gabriel F. T. Gomes ([[GabrielFTGomes|gftg]])
Line 43: Line 73:
 * Kaz Kojima (kkojima)
Line 45: Line 74:
 * Andreas Krebbel (andikr)
 * Thorsten Kukuk (kukuk)
Line 47: Line 78:
 * James Lemke (jwlemke)
Line 48: Line 80:
 * Stefan Liebler (stli)
Line 49: Line 82:
 * Rafał Lużyński (rluzynski,rl)
 * Mao Han
Line 50: Line 85:
 * Roland !McGrath (roland)
Line 56: Line 90:
 * Brooks Moses (brooks)
Line 57: Line 92:
 * Joseph Myers (jsm28)  * Paul Murphy ([[PaulMurphy|murphyp]])
 * Joseph Myers ([[JosephMyers|jsm28]])
 * Will Newton (willnewton)
Line 59: Line 96:
 * Carlos O'Donell (carlos)  * Carlos O'Donell ([[CarlosODonell|carlos]])
Line 61: Line 98:
 * Paul Pluzhnikov (ppluzhnikov)  * Paul Pluzhnikov ([[PaulPluzhnikov|ppluzhnikov]])
Line 63: Line 100:
 * Siddhesh Poyarekar (siddhesh)  * Siddhesh Poyarekar ([[SiddheshPoyarekar|siddhesh]])
 * Siva Chandra Reddy ([[SivaChandraReddy|sivachandra]])
 * Tulio Magno Quites Machado Filho (tuliom)
 * Torvald Riegel (torvald)
 * Maciej W. Rozycki (macro)
Line 67: Line 108:
 * Arjun Shankar (arjun)
Line 69: Line 111:
 * Rajalakshmi Srinivasaraghavan (raji)
Line 70: Line 113:
 * Chung-Lin Tang (cltang)
Line 71: Line 115:
 * Florian Weimer ([[FlorianWeimer|fw]])
 * Zack Weinberg (zack)
 * Mark Wielaard ([[MarkWielaard|mark]])
Line 72: Line 119:

Operating system port maintainers
 * Szabolcs Nagy (nsz)

===
Operating system port maintainers ===
Line 76: Line 124:
  * Roland !McGrath (roland)   * Thomas Schwinge (tschwinge)
  * Samuel Thibault < samuel.thibault@ens-lyon.org >
Line 80: Line 129:
Machine maintainers

 * aarch64 (ports)
=== 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.

 * aarch64
Line 84: Line 135:
 * arm (ports)   * Szabolcs Nagy (nsz)
 * arm
Line 86: Line 138:
  * Joseph Myers ([[JosephMyers|jsm28]])
 * alpha
  * Richard Henderson (rth)
 * C-SKY
  * Mao Han
 * hppa
  * Dave Anglin (danglin)
  * Carlos O'Donell ([[CarlosODonell|carlos]])
 * i386, x86_64, x32
  * Community review.
  * Carlos O'Donell ([[CarlosODonell|carlos]])
 * ia64
  * Mike Frysinger ([[MikeFrysinger|vapier]])
 * m68k
  * Andreas Schwab (schwab)
 * linux-generic
  * Chris Metcalf (cmetcalf)
 * microblaze
  * David Holsgrove (davidholsgrove)
 * mips
Line 87: Line 159:
 * alpha (ports)
  * Richard Henderson (rth)
 * hppa (ports)
  * Carlos O'Donell (carlos)
  * Jeff Bailey (jbailey)
 * i386, x86_64, x32 (libc)
  * Community review.
  * Carlos O'Donell (carlos)
  * Andreas Jaeger (aj)
 * ia64 (ports)
  * Mike Frysinger (vapier)
 * m68k (ports)
  * Andreas Schwab (schwab)
 * linux-generic (ports)
  * Chris Metcalf (cmetcalf)
 * microblaze (ports)
  * David Holsgrove (davidholsgrove)
 * mips (ports)
  * Joseph Myers (jsm28)
 * powerpc (libc)
  * Ryan S. Arnold (rsa,ryanarn)
  * Steven Munroe (sjmunroe)
 * powerpc (ports)
  * Ryan S. Arnold (rsa,ryanarn)
 * s390 (libc)
  * Andreas Krebbel (zommi)
 * nios2
  * Chung-Lin Tang (cltang)
 * powerpc
  * Tulio Magno Quites Machado Filho (tuliom)
 * RISC-V
  * Palmer Dabbelt (PalmerDabbelt)
  * Darius Rad
  * Andrew Waterman
  * DJ Delorie
 * s390
  * Andreas Krebbel (andikr)
Line 114: Line 171:
 * sh (libc)
  * Kaz Kojima (kkojima)
  * Thomas Schwinge (tschwinge)
 * sparc (libc)
  * Stefan Liebler (stli)
 * sh
  * No maintainer.
 * sparc
Line 119: Line 176:
 * tile (ports)
  * Chris Metcalf (cmetcalf)
Line 129: Line 184:
 * Amazon Linux
  * Samartha Chandrashekar < samarthc@amazon.com >
Line 131: Line 188:
 * Buildroot
  * Romain Naour < romain.naour@gmail.com >
Line 134: Line 193:
 * Google
  * Stan Shebs < stanshebs@google.com >
 * Fedora
  * [[CarlosODonell|Carlos O'Donell]]
  * [[SiddheshPoyarekar|Siddhesh Poyarekar]]
  * [[FlorianWeimer|Florian Weimer]]
Line 135: Line 200:
  * Mike Frysinger < vapier@gentoo.org >   * Andreas K. Hüttel < dilfridge@gentoo.org >
  * Sergei Trofimovich < slyfox@gentoo.org >
Line 139: Line 205:
  * Andreas Jaeger < aj@suse.de >
 * Red Hat
  * Carlos O'Donell < carlos@redhat.com >
  * Andreas Schwab < schwab@suse.com >
 * Red Hat Enterprise Linux
  * [[CarlosODonell|Carlos O'Donell]]
* [[FlorianWeimer|Florian Weimer]]
Line 143: Line 210:
  * Michael Matz < matz@suse.de >   * Andreas Schwab < schwab@suse.com >
Line 147: Line 214:
== 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:

 * Carlos O'Donell ([[CarlosODonell|carlos]])
Line 150: Line 222:
 * Carlos O'Donell (carlos)  * Carlos O'Donell ([[CarlosODonell|carlos]])
 * Kyle McMartin (kyle)
 * Siddhesh Poyarekar ([[SiddheshPoyarekar|siddhesh]])
 * Mike Frysinger (vapier)
Line 153: Line 228:
We maintain the text captchas on the wiki. You need login to sourceware.org followed by the ability to edit {{{/wiki/glibc.py}}} to add or modify existing captchas. The following people have permission to edit the wiki captchas:

 * Carlos O'Donell (carlos)
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:

 * Carlos O'Donell ([[CarlosODonell|carlos]])

== Maintainers for the patchwork instance ==
You need login to sourceware.org for the `patchwork` user.

 * Carlos O'Donell ([[CarlosODonell|carlos]])
 * Siddhesh Poyarekar ([[SiddheshPoyarekar|siddhesh]])

== 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.

 * Carlos O'Donell ([[CarlosODonell|carlos]])
 * Siddhesh Poyarekar ([[SiddheshPoyarekar|siddhesh]])
Line 160: Line 247:
 * Carlos O'Donell (carlos)
 * Roland !McGrath (roland)
 * Carlos O'Donell ([[CarlosODonell|carlos]])

As an anti-spam measure the ability to edit certain fields of created bugs is not possible e.g. 'editbugs' is restricted by default. If you would like 'editbugs' capabilities please just ask on libc-help@sourceware.org. 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, @suse.com, @suse.de, or @ubuntu.com accounts in bugzilla. Just ask.
Line 166: Line 254:
== Maintainers for BuildBot ==
The following people have access to the !BuildBot server and can help you to integrate !BuildBot-related patches.

 * Carlos O'Donell ([[CarlosODonell|carlos]])
 * Gabriel F. T. Gomes ([[GabrielFTGomes|gftg]])
 * Mark Wielaard ([[MarkWielaard|mark]])
 * Tulio Magno Quites Machado Filho (tuliom)
Line 167: Line 263:
This is not a table of designated component-wise maintainers (yet). 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. Over time, an additional column could be added to record ''component owners''.
||'''Component''' ||'''Reviewers''' ||
||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 ||
||manual ||Roland !McGrath ||
||math ||Andreas Jaeger ||
||network || ||
||nis || ||
||nptl ||Carlos O'Donell ||
||nscd ||Petr Baudis (don't block on him) ||
||regex || ||
||soft-fp || ||
||stdio || ||
||Everything else ||Carlos O'Donell ||
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, Siddhesh Poyarekar (for multiple precision bits) ||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 || ||
||tunables ||Siddhesh Poyarekar || ||
||Everything else ||Carlos O'Donell || ||

<<Anchor(AccountsOnSourceware)>>
Line 186: Line 289:
<<Anchor(AccountsOnSourceware)>>
Line 189: Line 291:
<<Anchor(SourceControlACL)>>
Line 190: Line 293:
<<Anchor(SourceControlACL)>>
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.
Project stewards 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. If you are requesting commit access for multiple people as part of a top-tier namespace request, please follow these instructions: [[GlibcGit#Name_Space_Request|Requesting a namespace]]. Individual developers requesting commit access should email overseers@sourceware.org using the following template:
{{{
TO: overseers@sourceware.org
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>
}}}
Line 194: Line 312:
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 [[http://www.kb.cert.org/vuls/html/report-a-vulnerability/|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. [[http://www.cert.org/blogs/certcc/2012/04/cert_triage_tools_10.html|Triage tools]] are available.
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.
Line 201: Line 317:
== Ohloh Group ==
We have an [[https://www.ohloh.net/|Ohloh]] Project for tracking [[https://www.ohloh.net/p/glibc|glibc]]. The project is moderated by [[CarlosODonell|Carlos O'Donell]].
== Open HUB Group ==
We have an [[https://www.openhub.net/|Ohloh]] Project for tracking [[https://www.openhub.net/p/glibc|glibc]]. The project is moderated by [[CarlosODonell|Carlos O'Donell]].

MAINTAINERS

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:

  1. Start by signing a copyright assignment for glibc.

    • Signing a copyright assignment will allow you to contribute to the parts of the project that require copyright assignment (almost all of it except for locales).
  2. Get yourself a patchwork account on patchwork.sourceware.org and go through the Patch Review Workflow

  3. 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).

  4. 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.
  5. Get yourself a sourceware account. Follow these instructions to get an account on sourceware.

  6. 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 get commit access.

  7. 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):

  • Ryan S. Arnold (rsa,ryanarn)
  • Mark Brown
  • Paul Eggert (eggert)
  • Jakub Jelinek (jakub)
  • Maxim Kuvyrkov (maximk,mkuvyrkov)
  • Joseph Myers (jsm28)

  • Carlos O'Donell (carlos)

  • Alexandre Oliva (aoliva)
  • Andreas Schwab (schwab)

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 libc-maintainers@gnu.org.

Maintainers (developers) for libc

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

  • Dave Anglin (danglin)
  • Albert Aribaud (aaribaud)
  • Ryan S. Arnold (rsa,ryanarn)
  • Petr Baudis (pasky)
  • Philip Blundell (pb)
  • Christian Brauner (brauner)
  • Thomas Bushnell (tb)
  • Paul Clarke (pc)
  • DJ Delorie (dj)
  • Liubov Dmitrieva (ldmitrie)
  • Ulrich Drepper (drepper)
  • Paul Eggert (eggert)
  • Mike Fabian (mfabian)
  • Mike Frysinger (vapier)

  • Gabriel F. T. Gomes (gftg)

  • Richard Henderson (rth)
  • Daniel Jacobowitz (drow)
  • Andreas Jaeger (aj)
  • Aurelien Jarno (aurel32)
  • Jakub Jelinek (jakub)
  • Geoffrey Keating (geoffk)
  • Mark Kettenis (kettenis)
  • Jan Kratochvil (jkratoch)
  • Andreas Krebbel (andikr)
  • Thorsten Kukuk (kukuk)
  • Maxim Kuvyrkov (maximk,mkuvyrkov)
  • Jeff Law (law)
  • James Lemke (jwlemke)
  • Dmitry V. Levin (ldv)
  • Stefan Liebler (stli)
  • H. J. Lu (hjl)
  • Rafał Lużyński (rluzynski,rl)
  • Mao Han
  • Greg McGary (gkm)

  • Allan McRae (allan)

  • Luis Machado (luisgpm)
  • Chris Metcalf (cmetcalf)
  • Jim Meyering (meyering)
  • David S. Miller (davem)
  • Brooks Moses (brooks)
  • Steven Munroe (sjmunroe)
  • Paul Murphy (murphyp)

  • Joseph Myers (jsm28)

  • Will Newton (willnewton)
  • Jonathan Nieder (jrnieder)
  • Carlos O'Donell (carlos)

  • Alexandre Oliva (aoliva)
  • Paul Pluzhnikov (ppluzhnikov)

  • Marek Polacek (mpolacek)
  • Siddhesh Poyarekar (siddhesh)

  • Siva Chandra Reddy (sivachandra)

  • Tulio Magno Quites Machado Filho (tuliom)
  • Torvald Riegel (torvald)
  • Maciej W. Rozycki (macro)
  • Andreas Schwab (schwab)
  • Thomas Schwinge (tschwinge)
  • Carlos Eduardo Seo (cseo)
  • Arjun Shankar (arjun)
  • Marcus Shawcroft (mshawcroft)
  • Franz Sirl (sirl)
  • Rajalakshmi Srinivasaraghavan (raji)
  • Alfred M. Szmidt (amszmidt)
  • Chung-Lin Tang (cltang)
  • Tom de Vries (vries)
  • Florian Weimer (fw)

  • Zack Weinberg (zack)
  • Mark Wielaard (mark)

  • Adhemerval Zanella (azanella)
  • Szabolcs Nagy (nsz)

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.

  • aarch64
    • Marcus Shawcroft (mshawcroft)
    • Szabolcs Nagy (nsz)
  • arm
    • Philip Blundell (pb)
    • Joseph Myers (jsm28)

  • alpha
    • Richard Henderson (rth)
  • C-SKY
    • Mao Han
  • hppa
    • Dave Anglin (danglin)
    • Carlos O'Donell (carlos)

  • i386, x86_64, x32
    • Community review.
    • Carlos O'Donell (carlos)

  • ia64
  • m68k
    • Andreas Schwab (schwab)
  • linux-generic
    • Chris Metcalf (cmetcalf)
  • microblaze
    • David Holsgrove (davidholsgrove)
  • mips
    • Joseph Myers (jsm28)
  • nios2
    • Chung-Lin Tang (cltang)
  • powerpc
    • Tulio Magno Quites Machado Filho (tuliom)
  • RISC-V
    • Palmer Dabbelt (PalmerDabbelt)

    • Darius Rad
    • Andrew Waterman
    • DJ Delorie
  • s390
    • Andreas Krebbel (andikr)
    • Martin Schwidefsky (schwidefsky)
    • Stefan Liebler (stli)
  • sh
    • No maintainer.
  • sparc
    • David S. Miller (davem)

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 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 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 the ability to edit certain fields of created bugs is not possible e.g. 'editbugs' is restricted by default. If you would like 'editbugs' capabilities please just ask on libc-help@sourceware.org. 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, @suse.com, @suse.de, or @ubuntu.com accounts in bugzilla. Just ask.

Maintainers for linuxthreads add-on

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

Maintainers for BuildBot

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

  • Carlos O'Donell (carlos)

  • Gabriel F. T. Gomes (gftg)

  • Mark Wielaard (mark)

  • Tulio Magno Quites Machado Filho (tuliom)

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, Siddhesh Poyarekar (for multiple precision bits)

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

tunables

Siddhesh Poyarekar

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

Project stewards 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. If you are requesting commit access for multiple people as part of a top-tier namespace request, please follow these instructions: Requesting a namespace. Individual developers requesting commit access should email overseers@sourceware.org using the following template:

TO: overseers@sourceware.org
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 Security Process 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 2019-08-12 11:44:03 by Stefan Liebler)