Subsystem maintainers

[Joseph S. Myers]

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