This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Subsystem maintainers


On Tue, 2014-10-07 at 14:07 -0400, Carlos O'Donell wrote:
> 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.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]