This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Subsystem maintainers
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Thomas Schwinge <thomas at codesourcery dot com>
- Cc: Torvald Riegel <triegel at redhat dot com>, Carlos O'Donell <carlos at redhat dot com>, <libc-alpha at sourceware dot org>
- Date: Wed, 8 Oct 2014 11:42:09 +0000
- Subject: Re: Subsystem maintainers
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1409232040060 dot 8132 at digraph dot polyomino dot org dot uk> <Pine dot LNX dot 4 dot 64 dot 1409301439570 dot 15186 at digraph dot polyomino dot org dot uk> <542AC26E dot 5070906 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1410071615260 dot 28196 at digraph dot polyomino dot org dot uk> <54342BE2 dot 6000006 at redhat dot com> <1412711085 dot 30642 dot 122 dot camel at triegel dot csb> <87bnpmrivo dot fsf at kepler dot schwinge dot homeip dot net>
On Wed, 8 Oct 2014, Thomas Schwinge wrote:
> > This would be fine with me. If we have areas of glibc where only a few
> > people (or, 1 person) are knowledgeable enough to maintain it, then we
> > can as well be honest about it :)
>
> I agree. So, basically, extend (and rename)
> <https://sourceware.org/glibc/wiki/MAINTAINERS#Reviewers_by_component>.
I don't think it's obvious that every defined area needs to / should have
a maintainer, or that everyone listed as a reviewer should thereby be
considered to have consensus for their patches in that area. (After all,
we decided to have community review for x86/x86_64 patches rather that
having maintainers who routinely apply their patches there without
separate review.)
At least initially I was thinking about areas that are reasonably
self-contained and specialized - even if we had stdio experts routinely
reviewing all patches in that area (and we could probably do with such;
Adhemerval's fmemopen patch has been pending review for some time), it
might still be a good idea for other people to review their patches, as
with x86 port patches.
Of the areas listed there, I'd say hurd, localedata, math, nis, nscd,
regex, soft-fp would be suitable for having subsystem maintainers in the
sense I suggest. In view of Andreas stepping down I'll also volunteer to
be such a subsystem maintainer for math, though I hope other people will
also continue to review patches there, especially where optimized .S
implementations are involved. (I also think questions of adding new
functions to the ABI, whoever is adding them, would best go to community
consensus - if I were to start adding new functions from TS 18661, for
example, it would be desirable to have agreement first that the functions
should indeed be added to the libraries in question, even if no-one else
reviewed the details of the implementations.)
--
Joseph S. Myers
joseph@codesourcery.com