This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
RE: Subsystem maintainers
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Carlos O'Donell <carlos at redhat dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Wed, 8 Oct 2014 09:39:50 +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>
Carlos O'Donell <carlos@redhat.com> writes:
> On 10/07/2014 12:22 PM, Joseph S. Myers wrote:
> > On Tue, 30 Sep 2014, Carlos O'Donell wrote:
> >
> >> On 09/30/2014 10:40 AM, Joseph S. Myers wrote:
> >>> Ping. This patch
> >>> <https://sourceware.org/ml/libc-alpha/2014-09/msg00544.html> is
> pending
> >>> review.
> >>
> >> Who do we expect to review these patches? There is a considerable
> amount of
> >> work required to review soft-fp, and at present I find it hard to be
> motivated
> >> for anything but hard float.
> >
> > (With reference to
> > <https://sourceware.org/ml/libc-alpha/2014-09/msg00679.html>.)
> >
> > Perhaps we should have subsystem maintainers for more areas than just
> > architecture ports, where the number of people interested in a
> particular
> > area is limited? The principle would be that changes by those people in
> > those areas are presumed to have consensus and not need someone else to
> > review them, in the absence of any actual objections that show the
> absence
> > of consensus (but it would still be the case that anyone could express
> > their concerns about such a change, or a change in such an area could
> > reach consensus through review by people other than the subsystem
> > maintainers, especially when it's just part of a global change, just as
> > today with architecture changes).
>
> I agree. We should have some kind of subsystem maintainers to simplify
> the process of finding an expert to review your patch, and simplifying
> the work for the subsystem maintainer.
>
> > I'd be willing to be a subsystem maintainer in this sense for soft-fp
> and
> > the conform/ tests.
>
> We should see consensus on the idea of subsystem maintainers.
>
> I'd like to see others comment that they are OK with the idea.
>From a newcomer's perspective it would help to know who has a good
understanding of each major area. The consensus based approach is good
but it is not always clear whether an OK from someone is really
sufficient or not. i.e. someone who has the slightest doubt about a
change could wait on the subsystem maintainer commenting even if others
say OK.
I would definitely agree that an expert in one area of glibc should not
be held up by lack of reviewers with enough interest or experience.
Matthew